/kind feature
Describe the solution you'd like
Support users that have a dependency on CoreOS by supporting Flatcar containers in CAPZ.
I suspect this will need additional support from the kubeadm bootstrap provider and image-builder support as well (https://github.com/kubernetes-sigs/cluster-api/issues/1582), since Flatcar is managed quite a bit differently than the currently supported OSs.
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
I'm going to close this one since it doesn't require any changes to the infra provider AFAIK and it's already being tackled from an image perspective in kubernetes-sigs/image-builder#248 and for bootstrapping in https://github.com/kubernetes-sigs/cluster-api/pull/3437
/close
@CecileRobertMichon: Closing this issue.
In response to this:
I'm going to close this one since it doesn't require any changes to the infra provider AFAIK and it's already being tackled from an image perspective in kubernetes-sigs/image-builder#248 and for bootstrapping in https://github.com/kubernetes-sigs/cluster-api/pull/3437
/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.
@CecileRobertMichon I think it may require infra-provider updates, it just that the image-builder work has been a huge thing for review and feedback.
I guess I was mis-remembering. Looking through the code it doesn't seem to have particular things jump out as blockers. There is a good chance we need a change to incorporate the ignition-bootstrap-provider, rather than just kubeadm-bootstrap-provider.
The big this is for us to work through the providers and get testing on this.
reopening to track testing / integration
/remove-lifecycle rotten
/reopen
@CecileRobertMichon: Reopened this issue.
In response to this:
reopening to track testing / integration
/remove-lifecycle rotten
/reopen
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.
/remove-lifecycle stale
@CecileRobertMichon nice. This is on our roadmap and I'm looking forward to making it happen.
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-contributor-experience at kubernetes/community.
/lifecycle stale
cc @invidian
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
Small update. We've got image-builder to build CAPI Azure images, but there is still some thing which needs to be resolved before we open the PR.
Changes proposed in https://github.com/kubernetes-sigs/cluster-api/pull/4172 works out of the box with CAPZ, except new cluster configuration template needs to be submitted including some minor differences in node configuration. Mentioned here: https://github.com/kubernetes-sigs/cluster-api/pull/4172#issuecomment-802771490.
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-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Most helpful comment
/remove-lifecycle rotten
Small update. We've got image-builder to build CAPI Azure images, but there is still some thing which needs to be resolved before we open the PR.
Changes proposed in https://github.com/kubernetes-sigs/cluster-api/pull/4172 works out of the box with CAPZ, except new cluster configuration template needs to be submitted including some minor differences in node configuration. Mentioned here: https://github.com/kubernetes-sigs/cluster-api/pull/4172#issuecomment-802771490.