-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create functions for composing nodeadm and bottlerocket user data #1341
Labels
kind/enhancement
Improvements or new features
Comments
flostadler
added
kind/enhancement
Improvements or new features
needs-triage
Needs attention from the triage team
and removed
needs-triage
Needs attention from the triage team
labels
Sep 6, 2024
flostadler
added a commit
that referenced
this issue
Sep 13, 2024
…1340) This change adds a new input property called `nodeadmExtraConfig` to the node group components. This property will allow injecting additional nodeadm sections into the user data. This can be virtually anything. Some data, a shell script, or additional nodeadm [`NodeConfig`](https://awslabs.github.io/amazon-eks-ami/nodeadm/). The nodeadm user data is a MIME multipart/mixed document. And every section has string based `content` and a MIME multipart `contentType`. Right now there's no straight forward way to generate types for the nodeadm `NodeConfig` because it's not schematized. Work for enhancing this is tracked here: #1341.
flostadler
added a commit
that referenced
this issue
Sep 13, 2024
…1340) This change adds a new input property called `nodeadmExtraConfig` to the node group components. This property will allow injecting additional nodeadm sections into the user data. This can be virtually anything. Some data, a shell script, or additional nodeadm [`NodeConfig`](https://awslabs.github.io/amazon-eks-ami/nodeadm/). The nodeadm user data is a MIME multipart/mixed document. And every section has string based `content` and a MIME multipart `contentType`. Right now there's no straight forward way to generate types for the nodeadm `NodeConfig` because it's not schematized. Work for enhancing this is tracked here: #1341.
flostadler
added a commit
that referenced
this issue
Oct 17, 2024
…1340) This change adds a new input property called `nodeadmExtraConfig` to the node group components. This property will allow injecting additional nodeadm sections into the user data. This can be virtually anything. Some data, a shell script, or additional nodeadm [`NodeConfig`](https://awslabs.github.io/amazon-eks-ami/nodeadm/). The nodeadm user data is a MIME multipart/mixed document. And every section has string based `content` and a MIME multipart `contentType`. Right now there's no straight forward way to generate types for the nodeadm `NodeConfig` because it's not schematized. Work for enhancing this is tracked here: #1341.
flostadler
added a commit
that referenced
this issue
Oct 17, 2024
…1340) This change adds a new input property called `nodeadmExtraConfig` to the node group components. This property will allow injecting additional nodeadm sections into the user data. This can be virtually anything. Some data, a shell script, or additional nodeadm [`NodeConfig`](https://awslabs.github.io/amazon-eks-ami/nodeadm/). The nodeadm user data is a MIME multipart/mixed document. And every section has string based `content` and a MIME multipart `contentType`. Right now there's no straight forward way to generate types for the nodeadm `NodeConfig` because it's not schematized. Work for enhancing this is tracked here: #1341.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello!
Issue details
AL2023 and Bottlerocket use structured configuration for the node and kubelet. This configuration is passed to the instance via the user data document (i.e. a
string
).Status Quo
AL2023 configuration is a MIME multipart/mixed document and can be interleaved with arbitrary data and bash scripts. Because of this we cannot reasonably expose it as typed data within the node groups. Instead it's an array of multi part sections:
Bottlerocket configuration has to be in TOML format. Because of that we can model it as a
object
. But it's lacking type information of the expected structure.Proposal
We can add functions to compose the expected
NodeConfig
yaml for nodeadm (i.e. AL2023) and bottlerocket's TOML config.One challenge here will be forward and backwards compatibility. We'll have to namespace the configuration like we do for kubernetes resources
E.g.
eks.nodeadm. v1alpha1.getNodeConfig({...})
.Bleeding edge users can leverage the untyped properties directly as an escape hatch in case the provider does not yet provide updated types for new versions.
Another challenge that needs to be solved is generating the types. Both nodeadm and bottlerocket provide schemas (openapi schema or k8s CRD), but their types are lacking the information we need. They're modeled as
object
as well (e.g. see).Affected area/feature
The text was updated successfully, but these errors were encountered: