Fix config group implementation to support edge cases

Registered by Khyati Sheth on 2014-04-07

The current config group implementation causes inconsistent state in some scenarios.

Consider this example for mysql:

Assume config group : configtest => {u'autocommit': 1, u'max_user_connections': 50, u'max_connections': 50} . All 3 parameters do not require a restart. This config group is applied to instance A.
Later configtest is updated using this command : trove configuration-update <config_test_id> '{"autocommit": 0} .
Here max_connections & max_user_connections are deleted from the config group using the update command. However since the param in the updated config group, autocommit, does not require a restart, the update operation as a whole does not require a restart. The values of max_connections & max_user_connections are not updated to their respective defaults on instance A. This leads to inconsistent states.

Similarly consider this other example:
Assume config group : configtest1 => {u'autocommit': 1}
This config group is applied to instance A.
Assume config group : configtest2 => { u'max_user_connections': 50}
Both these config groups contain parameters that do not require a restart.
When configtest2 is applied to instance A without detaching configtest1, it leads to inconsistent state. autocommit will hold the value 1 on instance A rather than the default value for autocommit.

As an enhancement to the current implementation, the guest agent should handle these edge use-cases & make a decision on whether the instance requires a restart or not, depending on the config group operation.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Khyati Sheth
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.