hi all

Hi Mathieu 🙂

Good morning folks! I have just published the github repo containing the current metal3 deployment code, see https://github.com/rancher-sandbox/baremetal. This is also where the SUSE metal3 team will publish their ongoing development artefacts. For example we have a first drop of moving things to helm with a new chart for the media server that I just merged before publishing the repo. Have a look and feel free to send PRs, issues etc.

hello everyone 🙂

👋

👋

@worried-electrician-89379 - firstly hello 😀 Will you or anyone else be going to Kubecon next week?

hello @rapid-van-91305 🙂

nice to see you here

unfortunately, indeed, I'm not going there either

Likewise, great to see you here. There are ~ 9 sessions related to CAPI at Kubecon next week. I thinks a record number for the project.

I'll share with you any interesting ones

has anyone tried to use the upstream kubeadm control plane provider with self-signed certs? I keep seeing this error in capi-kubeadm-control-plane-controller-manager.

E1027 20:24:29.009588       1 controller.go:317] controller/kubeadmcontrolplane "msg"="Reconciler error" "error"="failed to create remote cluster client: error creating client and cache for remote cluster: error creating dynamic rest mapper for remote cluster \"default/my-cluster\": Get \"<https://10.84.81.6:6443/api?timeout=10s>\": x509: certificate signed by unknown authority" "name"="my-cluster" "namespace"="default" "reconciler group"="<http://controlplane.cluster.x-k8s.io|controlplane.cluster.x-k8s.io>" "reconciler kind"="KubeadmControlPlane"

The self-signed root is mounted via the standard

kube-root-ca.crt

configmap.

Volumes:                                                                                                                             │
│   cert:                                                                                                                              │
│     Type:        Secret (a volume populated by a Secret)                                                                             │
│     SecretName:  capi-kubeadm-control-plane-webhook-service-cert                                                                     │
│     Optional:    false                                                                                                               │
│   kube-api-access-zn7qg:                                                                                                             │
│     Type:                    Projected (a volume that contains injected data from multiple sources)                                  │
│     TokenExpirationSeconds:  3607                                                                                                    │
│     ConfigMapName:           kube-root-ca.crt                                                                                        │
│     ConfigMapOptional:       <nil>                                                                                                   │
│     DownwardAPI:             true                                                                                                    │
│ QoS Class:                   BestEffort                                                                                              │
│ Node-Selectors:              <none>                                                                                                  │
│ Tolerations:                 <http://node-role.kubernetes.io/control-plane:NoSchedule|node-role.kubernetes.io/control-plane:NoSchedule>                                                        │
│                              <http://node-role.kubernetes.io/master:NoSchedule|node-role.kubernetes.io/master:NoSchedule>                                                               │
│                              <http://node.kubernetes.io/not-ready:NoExecute|node.kubernetes.io/not-ready:NoExecute> op=Exists for 300s                                               │
│                              <http://node.kubernetes.io/unreachable:NoExecute|node.kubernetes.io/unreachable:NoExecute> op=Exists for 300s

But kube-api-access doesn't seem to make use of it.

We have done the repo setup and scaffolding of the 2 providers: https://github.com/rancher-sandbox/cluster-api-provider-rke2

Now we can do the interesting stuff 🙂

👋 Howdy

@rapid-van-91305 @astonishing-stone-14417 Since RKE2 is an acronym and that I have some code already, I went ahead and changed the structs to

RKE2Xxxx

instead of

Rke2Xxxx

, this is not yet committed, so please let me know if you do not agree.

@cool-thailand-26552 I left a bunch of comments on the API PR, thanks a lot for starting it! Generally it looks great just some minor things to fix.

@rapid-van-91305 @astonishing-stone-14417 I am having multiple constant definitions with the same values like the following:

const (
	KernelDefaultsProtectionEnabled  KernelDefaultsProtectionPolicy = "enabled"
	KernelDefaultsProtectionDisabled KernelDefaultsProtectionPolicy = "disabled"
)

const (
	EtcdMetricsEnabled  EtcdMetricsExposurePolicy = "enabled"
	EtcdMetricsDisabled EtcdMetricsExposurePolicy = "disabled"
)

Is this overkill, or is it how it should be ?

Added a few comments to the API PR.

We should think about merging in the next few days so that we can start reconciliation implementation…..we can always refactor the API as we go along.

Agree, the API looks good enough, expect for some minor comments. We can address them later, it will be easier to review smaller changes. Also before first release we should be free to do breaking changes if needed.

@astonishing-stone-14417 @rapid-van-91305 I did implement most of what you mentioned in your comments from today. Could you do another pass please? Thanks

Sure, then lets merge 🙂

I've just approved the PR

Nice

The next step after merging the PR is defining our dev/test infrastructure, are we going to use docker provider?

Thanks!

@rapid-van-91305 Merge blocked because base branch contains commits that are not signed

@rapid-van-91305 @astonishing-stone-14417 Trying to give some thoughts to the way we can get RKE2 binaries on the machines, that would also work with Air-Gapped environments: 1. Having a different image for each version of RKE2: is that at all imaginable? How are images downloaded in the final user's environment? 2. Using cURL in cloud-init's runcmd to get binaries from a local HTTP server (would be a pre-requisite from a user's side) 3. Supposing the user has put all necessary images in a private container registry (also a pre-requisite, and solves a part of the problem, some binaries like the RKE2 binary still need to be transferred some how). I was already expecting this but indeed, secrets and ConfigMaps are limited to 1MiB size, and therefore are not designed for hosting files on the API. Since CAPI uses cloud-init, we don't have anyway to check in advance if node is air-gapped (e.g. checking if github.com resolves and check if we get a valid HTTP response within a short time frame) before installing RKE2, except maybe if we do a lot of bash scripting and run it using cloud-init, which should not be the goal of CAPI I imagine. Do you have thoughts about this ?