-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
rhos-18.0.10 FR 3
-
None
-
Important
-
Not Selected
-
False
-
False
-
-
0
-
0
Feature Overview
Currently, nova-operator handles each service's customserviceconfig.
However, some configuration needs to be written among services.
For example, [quota] section needs to be written for nova-api and nova-scheduler.
As a normal user, it is hard to identify what configuration is needed to be written in multiple services.
The current implementation has difficulties:
1. it is hard to find out what parameter is written to multiple services like nova-api, nova-scheduler and nova-conductor for some configuration.
2. Maintaining the duplicated configuration among services. As described above, quota configuration is need to be written for nova-api and nova-scheduler.
On the other hand, nova ignores the unrelated configuration even if it is written in configuration file.
To make it easy for users, I'd like to request to implement global customserviceconfig for nova.
The global customserviceconfig will work like below.
1. The configurations in global customserviceconfig is propagated to all nova services.
2. Each service's customserviceconfig still work to overwrite the configuration provided by global custom config.
By this new feature, our customer will have benefits:
1. They only manage the common configuration under global customserviceconfig.
2. We still provide the customserviceconfig feature per service for those who customize the configuration per service.
3. The new feature won't break the existing configuration because each service's customserviceconfig is prioritized than global customserviceconfig.
Goals
1. Add global customserviceconfig for nova
2. The configurations in global customserviceconfig will be propagated to all services configuration files.
3. Each service's customserviceconfig overwrite the configuration in global cusotmserviceconfig.
Done
1. Confirm the existence of global customserviceconfig for nova
2. The configurations in global customserviceconfig will be propagated to all services configuration files.
3. Each service's customserviceconfig overwrite the configuration in global cusotmserviceconfig.
Use Cases
We have a support case that nova's quota didn't work properly as expected.
In the support case, a user assigned quota configuration for nova-api but they didn't assign those configurations into nova-scheduler.
Because of that, openstack quota show replies the desired configuration as assigned in nova-api. However, instances couldn't be created over the default(10 VMs).
This was caused by nova-scheduler.
To prevent this kind of issue, we should have a global customserviceconfig for nova.
Out of Scope
In this activity, we limit the scope in nova-operator and openstack-operator.
Documentation
This feature requires an update of documentation to notify our users that we implement the new configuration and how to use it.
Questions to Answer
Background and Strategic Fit
Customer Considerations
Team Sign Off (Completion while in Planning status)
- All required Epics (known at the time) are linked to the this Feature
- All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
- Add - Reviewers name, Team Name
- Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
- Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone
Reviewed By | Team Name | Accepted | Notes |