Description
What problem are you trying to solve?
There is currently a tag
|
karpenterClusterNameTag = "eks:eks-cluster-name" |
that the AWS Karpenter resources get tagged with.
For those of us running Karpenter in places other than EKS, having a tag eks:eks-cluster-name is somewhat confusing because:
- inventory/filtering/etc regard the tagged items erroneously as part of a cluster
- there will be no corresponding EKS cluster
- there may actually be EKS clusters in the user account if we're running in AWS
That sounds like your problem @jkyros, we built this for eks, you're the weirdo running it downstream 😛
True. And we can carry patch it downstream if we have to, but I would love to keep hacks to a minimum where possible, and there may be other beneficiaries here for others running Karpenter outside of EKS clusters?
Ideally we'd be able to specify the tag it uses via some sort of ENV or arg, so in our case we could do something like: --karpenter-cluster-name-tag=rosa:rosa-cluster-name and then have inventory/filters/users that were actually looking for EKS items be correct still.
@maxcao13 was asking about this in slack https://kubernetes.slack.com/archives/C02SFFZSA2K/p1759187210807499, back in September and he didn't get a "hard no" so I thought maybe there might be some openness to discussing it?
And yes, this would mean giving up the ability to statically protect the tag with validation, e.g.
|
// +kubebuilder:validation:XValidation:message="tag contains a restricted tag matching eks:eks-cluster-name",rule="self.all(k, k !='eks:eks-cluster-name')" |
😞
How important is this feature to you?
Important enough that we'd probably want to carry patch it (and untangle/maintain the consequences) anyway if we're told "no". We'd be willing to do the work obviously if the idea would be entertained.
I understand there is history here and we did move from something less eks-specific (karpenter.sh/managed-by) to the current eks tag #6589 and changing it again is probably a pain, so we don't ask this lightly. We have just legitimately had customers/users/support asking because of confusion over a "nonexistent eks cluster" being referenced.
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Description
What problem are you trying to solve?
There is currently a tag
karpenter-provider-aws/test/hack/resource/pkg/resourcetypes/resourcetypes.go
Line 23 in a777942
For those of us running Karpenter in places other than EKS, having a tag
eks:eks-cluster-nameis somewhat confusing because:That sounds like your problem @jkyros, we built this for eks, you're the weirdo running it downstream 😛
True. And we can carry patch it downstream if we have to, but I would love to keep hacks to a minimum where possible, and there may be other beneficiaries here for others running Karpenter outside of EKS clusters?
Ideally we'd be able to specify the tag it uses via some sort of ENV or arg, so in our case we could do something like:
--karpenter-cluster-name-tag=rosa:rosa-cluster-nameand then have inventory/filters/users that were actually looking for EKS items be correct still.@maxcao13 was asking about this in slack https://kubernetes.slack.com/archives/C02SFFZSA2K/p1759187210807499, back in September and he didn't get a "hard no" so I thought maybe there might be some openness to discussing it?
And yes, this would mean giving up the ability to statically protect the tag with validation, e.g.
karpenter-provider-aws/pkg/apis/v1/ec2nodeclass.go
Line 99 in abb3a5a
How important is this feature to you?
Important enough that we'd probably want to carry patch it (and untangle/maintain the consequences) anyway if we're told "no". We'd be willing to do the work obviously if the idea would be entertained.
I understand there is history here and we did move from something less eks-specific (
karpenter.sh/managed-by) to the current eks tag #6589 and changing it again is probably a pain, so we don't ask this lightly. We have just legitimately had customers/users/support asking because of confusion over a "nonexistent eks cluster" being referenced.