Exporting ControlPlaneInitMutex

[nasusoba]

What would you like to be added (User Story)?

As a developer for other bootstrap provider, I would like to have ControlPlaneInitMutex (ref) exported, so that I do not have to duplicate the code in elsewhere.

Detailed Description

ControlPlaneInitMutex (control_plane_init_mutex.go) is providing functionality for the first and only control plane node to run init. It is not specific to kubeadm provider. For other bootstrap providers like capi k3s/ capi rke2 /etcdadm-bootstrap-provider, we also need it. But we need to copy this file, because control_plane_init_mutex.go is put inside an internal folder.

Anything else you would like to add?

Could I move this file to cluster-api/util, e.g., cluster-api/util/locking, so that it could be reused by other bootstrap providers?

Label(s) to be applied

/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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

[neolit123]

etcdadm-bootstrap-provider

there is a CAPI provider for etcdadm??

note that we have a plan to archive etcdadm.
https://github.com/kubernetes-sigs/etcdadm
kubernetes-sigs/etcdadm#395

ControlPlaneInitMutex (control_plane_init_mutex.go) is providing functionality for the first and only control plane node to run init

i agree that the concept of "init"/"join" is not unique to kubeadm.

[fabriziopandini]

The Cluster API project currently lacks enough active contributors to adequately respond to all issues and PRs.

As you https://cluster-api.sigs.k8s.io/user/manifesto#the-complexity-budget there is only a certain amount of complexity we can take at any time, and when the complexity budget runs out, bad things happen, quality decreases, we can’t fix bugs timely etc.

This applies also to request to transform CAPI in a generic library for other to use, and this is the reason why back in the 1.0 timeframe we moved most of our controller to private.

We also want to preserve the freedom to change implementation details of our controllers at any time without worrying about other consumers, and this mutex is de facto an implementation detaill.

This is why I think we should say no to this request.
Feel free to bring this up at the office hours if you want to discuss this

/close

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

The Cluster API project currently lacks enough active contributors to adequately respond to all issues and PRs.

As you https://cluster-api.sigs.k8s.io/user/manifesto#the-complexity-budget there is only a certain amount of complexity we can take at any time, and when the complexity budget runs out, bad things happen, quality decreases, we can’t fix bugs timely etc.

This applies also to request to transform CAPI in a generic library for other to use, and this is the reason why back in the 1.0 timeframe we moved most of our controller to private.

We also want to preserve the freedom to change implementation details of our controllers at any time without worrying about other consumers, and this mutex is de facto an implementation detaill.

This is why I think we should say no to this request.

/close

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