cluster-api-provider-openstack

cluster-api-provider-openstack copied to clipboard

/kind feature

Describe the solution you'd like I would like to be able to use Flatcar linux for the control plane and worker nodes with CAPO.

Anything else you would like to add: I was already able to bring up a working cluster. There is also image-builder PR I'm working on https://github.com/kubernetes-sigs/image-builder/pull/907. I'd be happy to work on this.

CAPO should already support ignitions (OCP use it) though I am not sure we have such e2e test so far..

I think this would be a kubeadm feature? What patches might we need in CAPO to support this?

If Ignition is already supported, then hopefully it should be similar to CAPZ, where we only add templates + e2e tests.

I was already able to create a working cluster:

$ k get node -o wide
NAME                                 STATUS   ROLES                  AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                                             KERNEL-VERSION    CONTAINER-RUNTIME
pawe3-control-plane-5e7b8f08-lp2l4   Ready    control-plane,master   13h   v1.22.9   10.6.0.176    <none>        Flatcar Container Linux by Kinvolk 3139.2.2 (Oklo)   5.15.43-flatcar   containerd://1.6.2
pawe3-default-699dba55-b8zq6         Ready    <none>                 13h   v1.22.9   10.6.0.64     <none>        Flatcar Container Linux by Kinvolk 3139.2.2 (Oklo)   5.15.43-flatcar   containerd://1.6.2
pawe3-default-699dba55-fqcpc         Ready    <none>                 13h   v1.22.9   10.6.0.193    <none>        Flatcar Container Linux by Kinvolk 3139.2.2 (Oklo)   5.15.43-flatcar   containerd://1.6.2
pawe3-default-699dba55-qswp2         Ready    <none>                 13h   v1.22.9   10.6.0.110    <none>        Flatcar Container Linux by Kinvolk 3139.2.2 (Oklo)   5.15.43-flatcar   containerd://1.6.2

From CAPO side it's only about providing templates and documentation I think.

Cross-posting here https://github.com/kubernetes/cloud-provider-openstack/issues/1923

OCCM doesn't start from helm chart with default values as of right now :(

Edit: this is sorted now.

There is no real support for Flatcar in image-builder. Some post-processing has to be applied to the QEMU image. I created an issue: https://github.com/kubernetes-sigs/image-builder/issues/937

Can you point me to places where:

• templates can be provided
• e2e tests should be added

There is also this issue https://github.com/kubernetes-sigs/image-builder/issues/939 but we can provider the dropin in the templates for the time being.

The default value for the OpenStack image to use is defined here: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/f040fc433cccbfd654c636e66e8717373a2f294c/test/e2e/data/e2e_conf.yaml#L112 And used in the e2e test, e.g. here: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/f040fc433cccbfd654c636e66e8717373a2f294c/test/e2e/suites/e2e/e2e_test.go#L686

Adding a second e2e job and setting the OPENSTACK_IMAGE_NAME env is probably not what we want. Link to e2e test job yaml

Maybe we can introduce a new variable OPENSTACK_FLATCAR_IMAGE_NAME and add a new e2e case similar to: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/f040fc433cccbfd654c636e66e8717373a2f294c/test/e2e/suites/e2e/e2e_test.go#L676

What's the goal here? I don't think the OS installed is relevant to CAPO, so I'm not especially interested in adding e2e tests just for the purposes of showing it also works on CAPO.

Or are we talking about adding a new release template which uses Flatcar? In that case we'd probably want a test which uses that template, although it could likely run as a periodic rather than a presubmit.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

@mdbooth yeah ideally I'd like to have the template for the Flatcar and make sure it isn't broken. Providing the template is quite easy. Any pointers where to start with the tests?

@kopiczko do you have a copy of the template you used?

Hi @mnaser we are using our own helm chart https://github.com/giantswarm/cluster-openstack/blob/main/helm/cluster-openstack with ignition.enable=true set. You can always helm template ... and turn it into a template if you wish.

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

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

/remove-lifecycle rotten

@kopiczko any progress on this? thanks

@lukasmrtvy I won't have time to work on that one in the nearest future I'm afraid. Possibly I'll be revisiting it at some point but no plans now.

@kopiczko could I please bug you to add a brief overall status of the PR and maybe a list of open TODOs to be implemented to wrap things up? It would make it easier for others to pick up your great work.