-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
BU Product Work
-
True
-
-
False
-
100% To Do, 0% In Progress, 0% Done
-
5
-
0
-
Program Call
Change Management and Maintenance Schedules for Standalone HCP
Feature Overview (aka. Goal Summary)
An elevator pitch (value statement) that describes the Feature in a clear, concise way. Complete during New status.
As a cluster Administrator I want to introduce change management in Hosted Cluster OCP, permitting administrators to have fine grained control of when pending changes are applied to the Control Plane and Worker nodes by introducing the concept of change management. Change management will allow multiple flexible options in managing update disruptions, but the expected use will allow admins to define recurring maintenance schedules to control the initiation and progress of updates.
Goals (aka. expected user outcomes)
The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.
- Systems (e.g. OCM) / Admins with appropriate access to the management cluster can define a maintenance schedule to protect sensitive workloads from rolling restarts outside of selected times during which workload disruptions are permitted.
- Those Systems / Admins can also exclude certain dates from potentially disruptive updates. These are common expectations for enterprise grade systems.
- Those Systems / Admins can define a timebound one-off exception to immediately apply changes.
- Those Systems / Admins can disable a maintenance schedule halting additional changes depending on the change granularity offered by various controllers.
- Those Systems / Admins can use home grown tools to customize update roll-outs when a recurring maintenance schedule is not appropriate for their use case.
- Admins of hosted clusters can request (via processes outside the scope of this feature) for Maintenance Schedules to be defined for their cluster on their behalf.
The feature also provides fine grained manual control over when updates are deployed when maintenance schedules do not fulfill the management cluster Administrator's requirements.
Requirements (aka. Acceptance Criteria):
A list of specific needs or objectives that a feature must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.
- https://github.com/openshift/enhancements/pull/1571 is accepted and merged
- A new ChangeManagementPolicy CRD is defined for change management, the resources are created in HostedCluster namespace.
- A controller is written which keeps the status of ChangeManagementPolicy resources up to date based on permissive state
Change Management Strategies
- HCP HostedCluster adds field for ChangeManagementPolicy resource and HyperShift observes its status to know when changes may be initiated
- HCP NodePools add a field for ChangeManagementPolicy resource and HyperShift observes its status to know when changes may be initiated
Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed. Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.
Deployment considerations | List applicable specific needs (N/A = not applicable) |
Self-managed, managed, or both | Self-managed HCP |
Classic (standalone cluster) | Yes |
Hosted control planes | No |
Multi node, Compact (three node), or Single node (SNO), or all | All |
Connected / Restricted Network | All |
Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) | All |
Operator compatibility | Cluster Version Operator, Machine Config Operator |
Backport needed (list applicable versions) | |
UI need (e.g. OpenShift Console, dynamic plugin, OCM) | OpenShift Admin Console(Optional) Potentially, OCM definitely |
Other (please specify) |
Use Cases (Optional):
Include use case diagrams, main success scenarios, alternative flow scenarios. Initial completion during Refinement status.
<your text here>
GitOps based management of cluster configuration is simplified by ensuring that git based changes are rolled out during permitted windows.
Questions to Answer (Optional):
Include a list of refinement / architectural questions that may need to be answered before coding can begin. Initial completion during Refinement status.
<your text here>
Out of Scope
High-level list of items that are out of scope. Initial completion during Refinement status.
HCP
Background
Provide any additional context is needed to frame the feature. Initial completion during Refinement status.
https://issues.redhat.com/browse/XCMSTRAT-223
Customer Considerations
Provide any additional customer-specific considerations that must be made when designing and delivering the Feature. Initial completion during Refinement status.
<your text here>
Documentation Considerations
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.
Add documentation for changemanagement policy
Interoperability Considerations
Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact? What interoperability test scenarios should be factored by the layered products? Initial completion during Refinement status.
- clones
-
OCPSTRAT-1695 Change Management and Maintenance Schedules for Standalone OCP
- Refinement
- links to