Multiple Environment Support

[chirino]

Support a way to deploy integrations across multiple environments like dev, staging, and production.

The environments could all be on a single OpenShift cluster, but it will be more likely that they will be spread out across multiple OpenShift clusters.

Current Design

• Every Syndesis installation will be an environment.
• An integration will support an export action which when used download an archive that holds the information needed to recreate the integration in a different environment.
• An import integration action will be supported (Perhaps in the integration listing page).
• Importing an integration for the first time will cause all connections that the integration uses to be created in the new environment. All connection settings which are not secrets will be copied across environments.
• Imported integration my require the user to go into each created connection and fill in secrets specific to the environment (remember secrets are not copied across environments).
• Loading an integration which does not have a fully configured connection should highlight/list those issues with :
  • links OAuth to client/secrets configured for the connector (if it uses OAuth)
  • links to take them to the edit pages for those connections so they can fix the connection settings.
• Reimporting a integration should update the integration, but not update the existing connections, only create new connections if they do not exist.

[chirino]

Please leave comments here if you think the current design needs to be updated. When accepted, I'll incorporate the feedback and update the description of this epic directly.

[chirino]

Issues to consider:

• how do we identify if an integration/connection has been imported? Do we just use the id as defined from the exporting system?
• what if an integration uses a technical extension? Does the technical extension also get exported?

[zregvart]

I think it makes sense to design this much in the way JEE has it (logical/named vs physical/concrete split), i.e. the name of the connection would serve as a logical link between environments (or we could think of another attribute if the usage of the name is too broad), that is to say I would not carry over secrets from one environment to the next, I think secrets usually define the environment. I think if the resource (e.g. connection) cannot be matched to a target user needs to map to an existing resource of the same type or create new resource beforehand (i.e. fail the import). I would also like to see API for export/import and a CLI tool (perhaps Maven plugin) to perform export/import.

[chirino]

@zregvart I think that CLI/Maven/API tooling is out of scope for this scenario. I think we can build that into future enhancements.

Yeah I think Name of the integrations/connection might be the better way to identify connections across environments as opposed to using internal ids.

[rhuss]

@chirino Do you have an update to this story ? I guess it's something we need to carry over to Sprint 20. Anything we can show on Friday ?

[chirino]

I've not had time to work on it. At risk to move into 20.

[chirino]

PoC demoed in Sprint 19 review