Provide more intellegent configuration template loading
Since new multi-datastore functionality trove user could choose register version of package and it's full name.
Problem comes when you what to use config for database with version A with database version B (which is greater or lower then version A), abstract or specific database do not hold out promises on allowing backward capability with config files applyment.
Blueprint information
- Status:
- Complete
- Approver:
- Michael Basnight
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- Accepted for future
- Implementation:
- Slow progress
- Milestone target:
- ongoing
- Started by
- Denis M.
- Completed by
- Denis M.
Related branches
Related bugs
Sprints
Whiteboard
denis_makogon: is this an issue anymore considering the 'manager' was moved to the datastore-version and not the datastore?
=======
=======
There are config and heat templates based on different datastores.
However, there is nothing to support different datastore-
These templates are needed if there are any different set of parameters in different version.
This would also help to support any kind of changes required for different version of install & configure steps done through heat provisioning using the heat templates, so we would be able to have different heat templates for different versions(if needed).
Currently, there is provision to have different datastore versions but there is no provision for different templates catering to these different versions(if need arise), so deployer is forced to either use same templates for each version or have a different deployment for a different version, even though with "trove create" command one has an option to provide different datastore_version for instances.
The change that should be implemented should work something like follows:
1. If a datastore version specific template exists then use it.
2. If there are no datastore version specific template use the default "datastore template".
So this workflow will preserve the current functionality and any existing deployments need not making changes following the upgrade, in short, it is BACKWARD COMPATIBLE.
=======
Justification/
=======
* If we need to have different templates for different datastore version, may be because of a change in the list of parameters in new version or a new parameter added in configuration steps of database carried through heat provisioning.
* This change would enable trove to support multiple datastore-
* This change is gonna preserve the current functionality with the functionality of "if version specific template exists then use it else use the default datastore template"
=======
Impacts
=======
* Configuration => This change does not updates any current configuration files.
* Database => This change does not makes any changes to existing database tables.
* Public API => This change does not alters any public API.
* Internal API => There is an update to communication between api and taskmanager, that it enables API to pass the datastore version name to taskmanager.
* Guest Agent => No changes to guestagent behavior.
Gerrit topic: https:/
Addressed by: https:/
Adds support for Datastore Version Specific Template