Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-1696

Change Management and Maintenance Schedules for Self-managed HCP

XMLWordPrintable

    • BU Product Work
    • True
    • Hide

      Blocked. Waiting on OCM changes.

      Show
      Blocked. Waiting on OCM changes.
    • 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

      • Maintenance Schedule Strategy

      • Restrictive Strategy

      • Permissive Strategy

      • 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.

              Unassigned Unassigned
              rh-ee-smodeel Subin M
              Justin Pierce, Pratik Mahajan, Scott Dodson
              Pratik Mahajan Pratik Mahajan
              Jianwei Hou Jianwei Hou
              Olivia Brown Olivia Brown
              Justin Pierce Justin Pierce
              Pratik Mahajan Pratik Mahajan
              Subin M Subin M
              Eric Rich Eric Rich
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: