docs: document the OS image lifecycle and provisioning model#307
docs: document the OS image lifecycle and provisioning model#307l0wl3vel wants to merge 1 commit into
Conversation
✅ Deploy Preview for metal-stack-io ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Signed-off-by: Benjamin Ritter <benjamin.ritter@x-cellent.com>
l0wl3vel
force-pushed
the
docs/os-image-lifecycle
branch
from
12584b1 to
3a6953a
Compare
|
|
||
| ## Image Lifecycle | ||
|
|
||
| Our images are derived from the official Docker images of the respective distribution. On top of that, we add the components required by the metal-stack infrastructure, e.g. FRR for routing-to-the-host and automation tools like [cloud-init](https://docs.cloud-init.io/en/latest/index.html) to run user provided post-install tasks. |
There was a problem hiding this comment.
We actually only install ignition
There was a problem hiding this comment.
I see we install cloud-init here and also mention userdata: https://github.com/metal-stack/metal-images/blob/master/debian/Dockerfile
What is cloud-init used for and is it not accessible to the end user?
There was a problem hiding this comment.
you are right, it was removed once back in time and added again :-) We should therefore mention both. Ignition is the one used for the gardener integration. Sorry for the noise.
There was a problem hiding this comment.
I do not think we have any E2E for cloud-init bootstrapping though. :(
There was a problem hiding this comment.
CAPMS would like to switch to cloud-init as far as I know. Maybe we can test it there.
There was a problem hiding this comment.
Yeah, there is an issue: metal-stack/cluster-api-provider-metal-stack#92
There was a problem hiding this comment.
Could someone, who has worked with these features, please write a paragraph about that? I am not that familiar with our implementation and use cases.
And lets please skip "to-be-implemented" features in the docs and instead create a follow up issue.
|
We should also mention, that the OS images have no dependency on the Kubernetes version used. Where do you think this information can be added? |
|
@simcod kubernetes distribution <-> node linux distribution compatibility is not a concern of metalstack, but of the K8s distribution used. There is also neither a guarantee that a certain setup (K8s distro, CNI , kubelet, exotic CRI) is compatible with a certain version of a distribution, due to missing features, like incompatible kernel version, systemd, iptables/nftables, cgroups v2, container runtime support. In our case that is gardener which has Certified Kubernetes Software Conformance, so I don't think it is something we should make any claims about the compatibility and only refer to the gardener docs. |
But we validate the released images with our integration tests where we iterate through all actually supported kubernetes versions which gardener and CAPI supports. |
|
@majst01 Sounds good. Where can I find the validation pipeline results, so I can link them? |
These results are in a private runner at one of our customers. It was planned for this year to make them public, but did not happen yet. |
You are absolutely right. It was just something we discussed with customers, so I thought it would be helpful to include in our documentation, too. We can also create an issue and add this, as soon as the validation pipelines can be added to the documentation. |
|
Issue created: metal-stack/metal-images#422 |
5 participants
Signed-off-by: Benjamin Ritter benjamin.ritter@x-cellent.com
Description
document the OS image lifecycle and provisioning model
Used AI-Tools ✨