NOTE: The concept of maintenance schedules is currently out of scope.  

User story:

Because hosted (hypershift) ROSA clusters will always require a maintenance schedule, as a user, I want to enter a maintenance schedule(s) for both control planes and machine pools.   This maintenance schedule may be individual (the user will choose the version in the future) or recurring where the user would enter a day/time for needed updating.  If the schedule is recurring I may choose to have the control plane updated at a different day/time than the machine pools.

Acceptance criteria:

• Users must choose between individual (and choose the exact version at a later time after the cluster has been created) and recurring where the cluster will be automatically updated.
• For hosted (hypershift) control plane if the user chooses a recurring schedule, users are required to enter a day and time (in UTC) for a maintenance start time.
• For recurring schedules, the user will be able to choose between using the same maintenance schedule day/time for worker nodes and control planes OR have a different day/time for all worker nodes than the control plane.
• For hosted (hypershift) control plane, users are required to enter a day and time (in UTC) for each maintenance start time.
• (if api is available)For hosted (hypershift) control plane, users are required to enter a day and time (in UTC) for each maintenance close time.
• Data entered will be shown on the review page (both standalone and hosted ROSA wizards)
• The next button will not move the user to the next step if required information, including maintenance window day(s)/times(s) are not provided.
• [technical] Data is prepared to be sent to the api 

Mockups:

Mockups | PD 1434

OLD Mockups:

------------------------------------------------------------------------------------------

Implementation details

Summary:

This is story is part of a set of changes for the cluster updates (HAC-2886, HAC-2887, HAC-2888). 

Notes:

There are numerous text and formatting changes from the existing cluster updates component(s).  An investigation will need to be done to determine if modifying the existing component should be done or if a new component just for Hypershfit should be created.

There is a new api endpoint to send update_policy for the control plane: /api/clusters_mgmt/v1/clusters/{cluster_id}/control_plane/upgrade_policies. This new endpoint should be used instead of the endpoint used for OSD/ROSA clusters.

The endpoint for the node pools isn't currently known.

There are numerous text and formatting changes from the existing cluster updates component(s).  An investigation will need to be done to determine if modifying the existing component should be done or if a new component just for Hypershfit should be created.

There is a new api endpoint to send update_policy for the control plane: /api/clusters_mgmt/v1/clusters/{cluster_id}/control_plane/upgrade_policies. This new endpoint should be used instead of the endpoint used for OSD/ROSA clusters.

The endpoint for the node pools isn't currently known.

API design doc - https://docs.google.com/document/d/17rgmcD6zX_jL28QnpHz3cPwYdE0wn7M9WpKau09JCfI/edit#