Limitations of minor version upgrade¶
This section describes the current limitations of version upgrade/downgrade:
- Service instance names: The service instance names for each of the services should be same in the current and new version of the application.
If the service instance names are different in the new version and the existing version of an application, then the existing service instances will not be available even after zero-downtime version upgrade.
The screenshot below shows an example for a service instance name conventions:
① Service instance name for the existing version of an application
② Service instance name that should be used for the new version of the same application
- Component names: During manual deployment of a new version of an application, do not use the same component names as available in the existing version. This might create name conflicts and usability issues.
In order to avoid such conflicts, while deploying a new version of an application, append -green at the end of the component name.
- Space names: If an application has different versions available and the versions are deployed with different space names, then version upgrade without downtime is not supported. In such cases, make sure to use the appname as spacename during deployment.
- User role configuration: During version downgrade of an application, the roles not available in the higher version of an application will not be configured. In such cases, configure the user roles again.
- Component URLs: Route conflicts could occur in either of the following cases:
- If an application has different components mapped with the same URLs
- Same components mapped to different URLs
It is difficult to identify changes between two versions in case of route conflicts.
To avoid such conflicts, you should map one URL to one component.
Any questions left?
Except where otherwise noted, content on this site is licensed under the MindSphere Development License Agreement.