Fix config group implementation to support edge cases
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_
Later configtest is updated using this command : trove configuration-
Here max_connections & max_user_
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_
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
- Started by
- Completed by