-
Initiative
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
None
-
Not Selected
-
False
-
False
-
-
0
-
0
Initiative Overview
This initiative will bring design and skeleton project for a tiering tool for RHOSO. Tiering has to be possible in three major resource areas which are compute area, storage area and network area. By tiering it is meant to limit resources of the specific areas and in the same time to ensure resource allocation for VM instances based on defined tiers (or performance profiles) and assigning those to the VM instances. We need to design suitable project/tool and prepare it for implementation of underlying resource areas logic by subject matter experts.{}
The idea here would be to create an operator (distinct from installer operators) that would hold the above definition and be responsible for configuring the various services to provide the performance tiers. The scoping would be around a node set, such that you apply a set of resource limits to a given set of nodes that all have the same physical limitations (i.e. the same network links, the same disk performance, and the same CPU arrangement). Grouping constructs such as host aggregates could be maintained by this operator according to the hosts in the node set to allow for targeted booting.
The definition of the profiles generally in terms of the resources they constrain and how they’re constrained is also part of this initiative. Then we apply some subset of those to a given scope of compute nodes (via aggregate) and also define the characteristics of those hosts for when we need to calculate percentages of the total host. The “relative_prio” number on each is just an arbitrary sorting key so if something like Watcher needs to take action, it could know “better to disrupt a silver with a migration than a platinum, because the platinum is more important”. This could also be inferred by the ordering in the “tiers:” key in the scopes, allowing for different relative importance meanings in different scopes.
Detailed draft of profile definition can be found in Tiering Proposal.
Goals
- Create higher level operator for tiering purposes
- Define performance profiles and have it verified by SMEs
- Design and prepare relevant CRDs
Requirements:
| Requirement | Notes | isMVP? |
|---|---|---|
| Shell operator for the per service controller implementation | yes | |
| CRD definition | yes | |
| Performance profiles per resource area | yes |
Done - Acceptance Criteria:
- shell operator is created and it is possible to proceed with implementation of controllers for each resource area
- all relevant performance profiles are defined
- CRDs for each resource area are defined and validated by implementers of resource area controllers
Out of Scope:
- Implementation of resource allocation enforcement
- is depended on by
-
RHOSSTRAT-1193 Hard tiering mechanism - storage part
-
- New
-
-
RHOSSTRAT-1194 Hard tiering mechanism - network part
-
- New
-
-
RHOSSTRAT-927 Hard tiering mechanism - compute part
-
- Refinement
-