-
Notifications
You must be signed in to change notification settings - Fork 284
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
Allow eksctl to generate TinkerbellTemplateConfig #3588
Comments
Relating #3411 for additional context. :) |
Thank you for reaching out to us! Forward your request to our internal team for discussions. |
@Cajga we can do this. I'm adding it to our backlog. |
There has been no activity on this issue for 60 days. Labeling as stale and closing in 7 days if no further activity. |
Although the default is more flexible now, this would be still very useful to have. |
There has been no activity on this issue for 60 days. Labeling as stale and closing in 7 days if no further activity. |
Just reiterating to keep this issue live: for bare metal users this would be a huge help as we need to use TinkerbellTemplateConfig in many real life use cases (dedicated network card for storage, bonding, use different interface for network than the one which was determined etc.) |
There has been no activity on this issue for 60 days. Labeling as stale and closing in 7 days if no further activity. |
/remove stale |
There has been no activity on this issue for 60 days. Labeling as stale and closing in 7 days if no further activity. |
/remove stale |
What would you like to be added: It would be really helpful if we could generate a TinkerbellTemplateConfig and be able to edit that. Or to have an option for
eksctl anywhere generate clusterconfig $CLUSTER_NAME --provider tinkerbell
to include TinkerbellTemplateConfig into the generated clusterconfig yaml.Why is this needed: As discussed in multiple bottlerocket os issues (first, second ) it is extremely likely that eno1 will not be the network interface name of the metal server but this is hard-coded into the current template. As such, we have to include TinkerbellTemplateConfig(s) in most of the cases.
However, the documentation includes an old example. The images listed there are outdated compared to what is really generated at cluster create.
In documentation the stream image action is using:
https://anywhere-assets.eks.amazonaws.com/releases/bundles/11/artifacts/raw/1-22/bottlerocket-v1.22.10-eks-d-1-22-8-eks-a-11-amd64.img.gz
But latest version of eks-anywhere is using:
https://anywhere-assets.eks.amazonaws.com/releases/bundles/18/artifacts/raw/1-23/bottlerocket-v1.23.9-eks-d-1-23-5-eks-a-18-amd64.img.gz
As a workaround, I've created a cluster and copied the template from $CLUSTER_NAME/generated/$CLUSTER_NAME-eks-a-cluster.yaml and edited that, then recreated the cluster with the proper template. But this is very inconvenient.
The text was updated successfully, but these errors were encountered: