Skip to content
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

[Feature request]: packaged snap variant of aws-iam-authenticator #631

Closed
rpocase opened this issue Sep 21, 2023 · 2 comments
Closed

[Feature request]: packaged snap variant of aws-iam-authenticator #631

rpocase opened this issue Sep 21, 2023 · 2 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@rpocase
Copy link

rpocase commented Sep 21, 2023

What would you like to be added?

Alongside the existing publication mechanisms, the Canonical team that owns Ubuntu EKS worker nodes would like to publish a snap to a snap store (aws/aws-iam-authenticator). This can be done out of tree, but having this located as close to upstream as possible is preferred.

Why is this needed?

The Ubuntu EKS worker AMIs are optimized to only provide the absolute minimum required to start a k8s worker and join an EKS control plane. The aws-iam-authenticator is currently delivered by a debian package that is distributed through a PPA. This is built for a specific distro version (20.04/Focal), which does not provide a new enough golang version to upgrade to a more modern aws-iam-authenticator version. To avoid this maintenance concern, we are switching aws-iam-authenticator to be distributed as a snap. Packaging in a snap allows us to more easily use different versions of golang without being tied to what is in the host distro.

Anything else we need to know?

We have an existing snapcraft.yaml and have published the aws-iam-authenticator as an unlisted snap. We want to ensure this gets adequate testing alongside upstream to gate future releases before making this publicly searchable. We have confirmed this works for our initial EKS use case, but there are likely corner cases we are not adequately testing.

@rpocase rpocase added kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Sep 21, 2023
@dims
Copy link
Member

dims commented Sep 21, 2023

@rpocase Could we switch over the pattern. could you monitor the tags in this repository and when a new one gets created you can then do what you need in your own infra to do what you need to do?

We'd like to avoid pushing custom artifacts specific to vendors from community owned resources. Hope that is ok.

Canonical folks are very welcome to join, help the project and keep things going here for sure! Looking forward to your involvement

@rpocase
Copy link
Author

rpocase commented Sep 21, 2023

@dims I'm certainly open to that. The only big concern is getting the right level of testing against the released package. We'll start working on new infra asap and I'll link the issue when we have something ready for public viewing.

@rpocase rpocase closed this as completed Sep 21, 2023
@rpocase rpocase closed this as not planned Won't fix, can't repro, duplicate, stale Sep 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants