📖 CAEP: ControlPlane

[detiber]

What this PR does / why we need it:

Adds a CAEP for ControlPlane Management

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: detiber

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [detiber]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vincepri]

/milestone v0.3.0

[detiber]

/assign @dlipovetsky @randomvariable @chuckha @ncdc @vincepri

[ncdc]

EOD here, but I have a couple of initial comments. Will try to review more tomorrow.

[vincepri]

/kind proposal

[vincepri]

Thank you for putting this proposal together, it's a great step in the right direction.

The comments outlined below are a mix of major and minor questions, given the amount of comments, we should probably go over them on Zoom later today, or it's also fine to address them async if you all prefer.

[hardikdr]

Thanks for the proposal, really nice work.
One question though:
Should we explicitly define the minimal contract which xyz-control-plane-controller should adhere to, as part of this CAEP?

• Eg, homogeneous status/or-something across XyzControlPlane CRDs, which should be initialized/maintained by respective control-plane-controllers.
• This proposal does talk many details of kubeadm-cp-controller, but I was also hoping for one generic-behavioral contract.
• Or is it already mentioned and I missed it?

[ncdc]

@hardikdr to date, we have not done a very good job of writing any behavioral contracts. I have opened #1727 to do this for control plane providers.

[detiber]

@ncdc Added a current non-goal for the followup work related to stable api endpoints, we already have the current mechanism for using cluster.Status.APIEndpoints as part of the Constraints and Assumptions

[detiber]

@hardikdr I believe I've addressed your inline comments.

I've also updated the non-goals to identify that documenting the exact interoperability mechanism for additional control plane providers will be handled as followup work and tracked by the issue that @ncdc linked.

[detiber]

@chuckha @akutz @jaypipes @alexbrand @pablochacin @randomvariable @rsmitty @dlipovetsky @jzhoucliqr @sbueringer @CecileRobertMichon @hardikdr I believe all outstanding comments have been addressed. Please take a look, I'm hoping that we can go ahead and get this merged to unblock work to start on the initial implementation.

[ncdc]

We would like to go with lazy consensus and plan to merge this on Wednesday as long as there are no blocking comments (will discuss at the community meeting)

[moshloop]

Uniquely mark the existing replica machine through setting an annotation and persisting the change (cluster.x-k8s.io/control-plane/selected-for-upgrade)

My only comment is to change this from an annotation to a label, so that it can be used in labelSelector

[detiber]

Uniquely mark the existing replica machine through setting an annotation and persisting the change (cluster.x-k8s.io/control-plane/selected-for-upgrade)

My only comment is to change this from an annotation to a label, so that it can be used in labelSelector

Are you okay if we address this after merging as a followup issue?

[moshloop]

Are you okay if we address this after merging as a followup issue?

Yes
/lgtm

[detiber]

Created #1764 to address the feedback on the label vs annotation for upgrade selection.