Provide more intellegent configuration template loading

Registered by Denis M.

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:
milestone icon ongoing
Started by
Denis M.
Completed by
Denis M.

Related branches

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-version-specific templates.

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/Benefits
============================================================================

* 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-version-specific config & heat templates.

* 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://review.openstack.org/#q,topic:bp/config-template-per-package-or-datastore-version,n,z

Addressed by: https://review.openstack.org/74843
    Adds support for Datastore Version Specific Template

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.