fsat
commented
7 years ago It does make sense for 2 bundles one older and newer to run alongside each other. A rolling upgrade use-case would be an example of this. In fact we introduced the --affinity switch to ensure the new bundle runs on the same machine as old's for those bundles which has state persisted on file system.
- How should we identify that there are two services/applications running which are essentially the same ? Is the bundle-name enough ?
We use bundle name and compatibility-version. The convention is for bundle versions which have the same name and compatibility-version, we can assume these bundles are binary compatible.
The Bundle Configuration documentation talks more about this.
- What should the restore process do ?
I think the restore process should load the v1, and then run v1 with --affinity v2. At this moment we can't tell if a bundle has a persistent state on the file system, so running with --affinity to a running, existing and compatible bundle is the safest option.
- Is this a problem for restore to solve or load ?
I'd say this is a problem for restore. I definitely think keeping the load logic simple as it is at the moment is the way to go.
Scenario:
If we are restoring a conductr backup to a destination cluster which already has a version of a bundle running then what should we do ?
Concrete example :
We have a payments service running in both the source (say v1) and destination cluster (say v2). Both of these instances of the application will have different bundle-ids. It would not make sense to have two versions of the same application running in the same cluster (or may be it does).
Ideally the operator should have control to either override the destination cluster (may be post a warning message). There are many paths we can take. Opening this up for discussion.