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

kapp injects label in Service Selector but not StatefulSet Pod Template #753

Open
frimik opened this issue May 14, 2023 · 1 comment
Open
Labels
bug This issue describes a defect or unexpected behavior discussion This issue is not a bug or feature and a conversation is needed to find an appropriate resolution helping with an issue Debugging happening to identify the problem

Comments

@frimik
Copy link

frimik commented May 14, 2023

Service has its selector modified by kapp:

apiVersion: v1
kind: Service
spec:
  selector:
    app.kubernetes.io/component: prometheus
    app.kubernetes.io/instance: k8s
    app.kubernetes.io/name: prometheus
    app.kubernetes.io/part-of: kube-prometheus
    kapp.k14s.io/app: "1684079013099136212"

Leading to the Service not having any matching Pods.

Whereas StatefulSet does not have its spec.template.metadata.labels modified:

spec:
  template:
    metadata:
      labels:
        app.kubernetes.io/component: prometheus
        app.kubernetes.io/instance: k8s
        app.kubernetes.io/managed-by: prometheus-operator
        app.kubernetes.io/name: prometheus
        app.kubernetes.io/part-of: kube-prometheus
        app.kubernetes.io/version: 2.43.0
        operator.prometheus.io/name: k8s
        operator.prometheus.io/shard: "0"
        prometheus: k8s

Why is the selector modified at all?

What steps did you take:

  • Define a Service
  • Define a StatefulSet
  • Define selectors in Service to match the Labels in the StatefulSet Pod Template.
  • Deploy these two via kapp.

What happened:

  • kapp adds label to the Service
  • kapp adds label to the Service selector
  • kapp adds label to the StatefulSet.
  • kapp does NOT add labels to the StatefulSet Pod Template.

What did you expect:

One of:

  • label to not be added in Service selector
  • label to be added in Pod Template

Anything else you would like to add:

I would expect kapp to "just work" for passing something this simple throuigh it.

Environment:

  • kapp version (use kapp --version): kapp version 0.54.3
  • OS (e.g. from /etc/os-release): Ubuntu 22.04.1 LTS
  • Kubernetes version (use kubectl version) v1.22.17

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

@frimik frimik added bug This issue describes a defect or unexpected behavior carvel triage This issue has not yet been reviewed for validity labels May 14, 2023
@praveenrewar
Copy link
Member

Hi @frimik!
kapp has some default labelScopingRules and ownershipRules to inject it's labels into resources. By default, kapp should inject the labels into the spec.template.metadata.labels of a statefulset (

- apiVersionKindMatcher: {apiVersion: apps/v1, kind: StatefulSet}
), unless you have the kapp.k14s.io/disable-default-ownership-label-rules annotation present (if this is not the case, could you share your StatefulSet yaml?). I tried creating a StatefulSet and I could see the labels under spec.template.metadata.labels.

@praveenrewar praveenrewar added helping with an issue Debugging happening to identify the problem discussion This issue is not a bug or feature and a conversation is needed to find an appropriate resolution and removed carvel triage This issue has not yet been reviewed for validity labels May 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue describes a defect or unexpected behavior discussion This issue is not a bug or feature and a conversation is needed to find an appropriate resolution helping with an issue Debugging happening to identify the problem
Projects
Status: No status
Development

No branches or pull requests

2 participants