Improved access to the cloud-init interface

[alanmeadows]

/kind feature

Describe the solution you'd like
The kubeadm bootstrap provider should support additional cloud-init interfaces that are commonly used in production systems.

Today, only a few are supported: https://github.com/kubernetes-sigs/cluster-api-bootstrap-provider-kubeadm/blob/master/cloudinit/cloudinit.go#L34-L42

Even some of these options, for instance, NTP, do not support the full gamut of available options:

For example: https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=ntp#ntp

While you can use these basic building blocks, for instance, writing files or scripts, and calling them prior to join via PreKubeadmC, end-users will end up with operating system specific scriptlets baked into their kubeadm config yaml for common operations such as partitioning secondary storage, mounting it, and so on. For example:

https://cloudinit.readthedocs.io/en/latest/topics/examples.html#adjust-mount-points-mounted
https://cloudinit.readthedocs.io/en/latest/topics/examples.html#disk-setup

[alanmeadows]

Parts of this may be a duplicate of #2994

[vincepri]

cc @CecileRobertMichon

[CecileRobertMichon]

@alanmeadows see #3066 and proposal #3048. That proposal is scoped to disk_setup, fs_setup, and mounts.

[vincepri]

/milestone Next

Needs more discussion on the future of CABPK.

[detiber]

One of the things we've discussed in the past is honoring the Format field to support outputting config other than cloud-init (such as ignition or other bootstrapping tools): #1582

If we do still intend to do that, then we need to be cautious around what config fields we support since there is not 100% parity between the different bootstrapping tools as to the features they support.

As @CecileRobertMichon and others mentioned in other conversations related to this topic, it would be great if we could find a way to disentangle the cloud-init requirement from the bootstrap provider as it sits today and have a way for it to do it's thing closer to the point of use rather than the way we currently use it today.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[detiber]

/lifecycle frozen

[vincepri]

Closing in favor of #3761

/close

[k8s-ci-robot]

@vincepri: Closing this issue.

In response to this:

Closing in favor of #3761

/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/test-infra repository.