feat: create clusters service control plane in backend - #4821
Conversation
|
Skipping CI for Draft Pull Request. |
This also bumps it for 4.19 as it is still around. This is interim bump until Azure#4821 is merged that will allow us to automatically pick the latest
Manyanda Chitimbo (machi1990)
left a comment
Manyanda Chitimbo (machi1990)
left a comment
There was a problem hiding this comment.
Did an initial review, left some comments.
Manyanda Chitimbo (machi1990)
left a comment
Manyanda Chitimbo (machi1990)
left a comment
There was a problem hiding this comment.
Jakob Gray (@JakobGray) I see that some changes to allow the cluster id to be missing are in here; let's sync those with the changes in #4752 as well
There was a problem hiding this comment.
In order for the frontend and backend images to stay compatible with a +/-1 version skew, this probably needs to be split into multiple pull requests.
Consider if we introduce this as is but the frontend and backend images don't get deployed simultaneously for some reason. We could potentially be in a situation where neither the frontend nor backend pods are making the CS call for cluster creation.
The first pull request should introduce the new backend controller but leave in place the CS call in the frontend. So the new controller will initially be dormant.
Once that's fully deployed, a second pull request can remove the CS call in the frontend, at which point the backend controller will take over.
668c9ce to
e4d3fdd
Compare
|
/lgtm |
|
/retest-required |
|
/retest |
Move CS cluster creation out of OperationClusterCreate into a dedicated ClusterClusterServiceCreate controller. The new controller waits for ControlPlaneDesiredVersion to resolve the install version, creates the CS cluster (or reuses one matched by Azure metadata), and persists ClusterServiceID on the cluster document. OperationClusterCreate now polls CS provisioning status via that stored ID instead of operation.InternalID. BuildCSCluster prefers the resolved DesiredVersion from ServiceProviderCluster when building the CS cluster. Async cluster installation will not take affect until cluster creation is removed from the frontend.
e4d3fdd to
a86a465
Compare
|
rebased solving conflicts |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JakobGray, miguelsorianod The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| func (c *operationClusterCreate) shouldReconcileOperationAndResourceStatus(cluster *api.HCPOpenShiftCluster) bool { | ||
| return cluster.ServiceProviderProperties.DeletionTimestamp == nil && | ||
| cluster.ServiceProviderProperties.ClusterServiceID != nil | ||
| } |
| subscription, err := c.subscriptionLister.Get(ctx, key.SubscriptionID) | ||
| if err != nil { | ||
| return utils.TrackError(err) | ||
| } |
|
/retest |
1 similar comment
|
/retest |
|
Jakob Gray (@JakobGray): The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/retest-required |
What
Move CS cluster creation out of OperationClusterCreate into a dedicated
ClusterClusterServiceCreate controller. The new controller waits for
ControlPlaneDesiredVersion to resolve the install version, creates the CS
cluster (or reuses one matched by Azure metadata), and persists
ClusterServiceID on the cluster document.
OperationClusterCreate now polls CS provisioning status via that stored ID
instead of operation.InternalID. BuildCSCluster prefers the resolved
DesiredVersion from ServiceProviderCluster when building the CS cluster.
Async cluster installation will not take affect until cluster creation
is removed from the frontend.
Why
The clusters service control plane is currently created synchronously during the create flow and uses hard coded versions derived from the customer desired version. By moving to an asynchronous approach we reduce create time and have clusters service deployment managed in the background. This will also allow us time to lookup the desired version from Cincinnati.
Testing
Includes unit tests. Integration and end-to-end testing with the controller functional is done in #5709.
Special notes for your reviewer