As a deployment engineer I would like to be able to leverage deployment configuration history for my cluster as a base for decision making.
For example, I need to have an opportunity to know what actually changed in the cluster since previous (or even earlier) times.
This information is sometimes crucial. E.g. I want to have an ability to inject tasks into deployment graph based on what actually changed in graph configuration.
As an example, when I change mysql configuration (something like max_connections), I need to perform mysql restart one by one as opposed to parallel installation in order to maintain the cluster operating. This cannot be done without actual knowledge of what are the new nodes and what are the old nodes in the cluster or whether this deployment is a new one or is a redeployment of previously deployed cluster.
This info may also be required for changes such as backend switching for glance/keystone or may be needed for plugins to alter their behaviour depending on cluster metadata change.
Currently, such a history does not exist which makes satisfaction of aforementioned use cases impossible. It should not be a rocket science to store cluster configuration in the database before sending it to the nodes being deployed.
Additional fields for ‘tasks’ model should be added to store serialized data, unserialized settings and unserialized network configuration associated with particular Nailgun task.
Add 3 new fields with deployment data into ‘tasks’ table with type ‘JSON’
There will be a REST API handler allowing to get serialized data, unserialized settings and unserialized network configuration for specified Nailgun task
|GET||/api/transactions/ :transaction_id/ deployment_info||get serialized data for a nailgun task||false|
|GET||/api/transactions/ :transaction_id/ settings||get settings for a nailgun task||false|
|GET||/api/transactions/ :transaction_id/ network_configuration||get network configuration for a nailgun task||false|
The methods should return the following statuses in case of errors:
GET method returns JSON
Fuel Client has to show stored information for particular Nailgun task. New command should be added:
fuel2 task 1 deployment-info download --file deployment-info.yaml fuel2 task 1 settings download --file settings.yaml fuel2 task 1 network-configuration download --file networks.yaml
Wait for ConfigDB full implementation or Solar integration, which will happen only with N release
Should be disabled for pre-9.0 clusters
User will be able to get history of all the changes and conduct better troubleshooting
Non-significant overhead for Postgres DB layer
Flexible deployment workflow generation and LCM support
Only feature-related documentation
See Proposed Changes section
Ability to fetch deployment info data for any particular nailgun task being run