-
Feature
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
Not Selected
-
False
-
False
-
-
L
-
-
0
-
0
-
rhos-workloads-evolution
Feature Overview
As a customer i am interested in combining Watcher strategies. for example:
- Combining Zone migration / evac for day 2 maintenance with workload balancing so i'll have the optimal spread across my functioning nodes
- Combining Node consolidation with workload balancing so i’ll be able to shutdown underutilized nodes and have the workload being spread optimally on my other nodes
Goals
- Combination of various strategies will enable to execute complex resource balancing in single plan
- Currently one strategy execution needs to end first before another can start which sometimes might end with instances moving multiple times within the cloud.
Requirements
| Requirement | Notes | isMVP? |
|---|---|---|
| Zone migration with workload balacing | Yes | |
| Node consolidation with workload balacing | Yes | |
| multiple workload balancing strategies with different metrics under different weights | Could be addressed in a different way when considering our tiering effort (currantly captured in RHOSSTRAT-833) | No |
Done
Using Watcher interface it is possible to combine and execute multiple strategies together to lower total number of actions required for having the cloud in a requested state.
Documentation of how to layer said strategies to be used in tandem
Use Cases
- Workload consolidation and workload balancing strategies
- Zone migration and workload balancing strategies
- Multiple balancing strategies based on variety of metrics
- Network latency would be most used metric to balance from with additional metrics
Out of Scope...
Documentation Considerations ...
Questions to Answer
- Should multiples strategies be executed sequentially or in a composition of multiple algorithms?
- Are multiple workload balancing strategies with different metrics under different weights the core mechanism to support tiering ?
Background and Strategic Fit...
Customer Considerations...
Team Sign Off
- 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 |
- …
- is related to
-
OSPRH-21082 Tiering mechanism and related features discussion
-
- Closed
-