-
Notifications
You must be signed in to change notification settings - Fork 110
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
kapp deploy adds unnecessary selector to service #381
Comments
That label is added by You can however disable the addition of the label by using the #...
metadata:
annotations:
kapp.k14s.io/disable-default-label-scoping-rules: ""
#... Is this a service that is not supposed to have selectors at all? |
Thank you. Hmm... We probably can use the workaround but if possible we don't want to add the label as we want to test the same yaml manifests which we will ship.
The service supports to have selector as |
Do you think a key in kapp Config which lets you disable label scoping for all resources is something that will help your use case better? |
Hmm... Honestly I am not sure the answer. cc @dprotaso who introduced Hi @dprotaso 👋 For the context of this issue, kapp inserts an additional selector |
I think we can just use the annotation to opt out of this behaviour. We can create an ytt overlay to add it to the resources we need kapp.k14s.io/disable-default-label-scoping-rules: "" |
@nak3 does this method work for you? (Closing this issue for now. Feel free to reopen it if you feel like we can help you improve this workflow!) |
@dprotaso Could you please send the PR? I am not familiar with the usage of kapp. |
I do wonder, if by default, if the Service doesn't have a matching deployment/pod then the label shouldn't be applied. |
I bumped into this issue while deploying kube-prometheus-stack. I render kube-prometheus-stack helm chart and then pipe the output to In general, it seems reasonable to have additional labels added by kapp. But I don't quite understand why selector labels are also altered. |
Hi @Zebradil !
Thanks for sharing your feedback. Currently we are trying to figure out the best way to disable this. Since the existing kapp apps would already have these selector labels, disabling them would result in immutable field errors for Deployments, so we need to figure out a way to make this backward compatible. |
Thanks @praveenrewar, |
You'll probably want
to redeploy w/o the added annotations, and force delete if patch fails due to immutable fields. Anyway, shouldn't kapp be adding this info to resources as an annotation not a label? |
work around carvel-dev/kapp#381 where kapp adds unwanted labels that break the kube-prometheus service selctor
@ringerc annotations are not "searchable", i.e. they are not indexed, so labels are used so that kapp can track the resources that are part of an app. |
@praveenrewar Makes sense, though it's a bit painful when interacting with operators. Can kubernetes ApplySets (https://kubernetes.io/blog/2023/05/09/introducing-kubectl-applyset-pruning/) help? They seem to be intended to standardise this sort of resource tracking. |
@ringerc ApplySets also use labels, however I agree that using them would increase the interoperability between different tools (which was one of the goals of introducing ApplySets, other than improving kubectl prune, related KEP). By the way this issue comes up because kapp also adds some selectors to services, deployments and statefulsets, which is causing the issue, and I agree that this behaviour should have been opt in, but due to backward compatibility we can't just remove it. |
An opt-in to remove the addition to selectors would be fantastic and would mostly solve this issue. |
Yep, for the same reason we introduced the flag |
What steps did you take:
Just create a svc with
kapp deploy
, for example:What happened:
kapp.k14s.io/app: "1638062141457992726"
as:What did you expect:
kapp.k14s.io/app: "1638062141457992726"
.Environment:
kapp --version
):Build on 4b9a9e6
The text was updated successfully, but these errors were encountered: