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 deploy command changing K8S ServiceAccount label value #974

Open
jhflemos opened this issue Jul 1, 2024 · 4 comments
Open

Kapp deploy command changing K8S ServiceAccount label value #974

jhflemos opened this issue Jul 1, 2024 · 4 comments
Labels
bug This issue describes a defect or unexpected behavior carvel accepted This issue should be considered for future work and that the triage process has been completed

Comments

@jhflemos
Copy link

jhflemos commented Jul 1, 2024

What steps did you take:

  1. Ran kapp deploy -a <APP_NAME> --diff-run --diff-changes=true -f ./app.yaml --into-ns <APP_NAMESPACE> --namespace <KAPP_CONTROLER> --default-label-scoping-rules=false.

What happened:
The value of ServiceAccount label was changed/converted when I ran kapp deploy command.

Original manifest in K8S:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-name
  labels:
    github.com/sha-short: "1b85fe5e"
...

New manifest to be deployed in K8S:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-name
  labels:
    github.com/sha-short: "934881e3"
...

The new value of github.com/sha-short label is being changed/converted to "934881000" instead "934881e3".

What did you expect:
The github.com/sha-short label continues using the label as defined in the manifest.

Anything else you would like to add:
If you change the final of the value for "e1", "e2", "e4", kapp command will change/convert to "0", "00", "0000" respectively.

Environment:

  • kapp version (use kapp --version): 0.62.1
  • OS (e.g. from /etc/os-release): MacOs 14.5 (23F79) and Ubuntu 22.04.4
  • Kubernetes version (use kubectl version): v1.30.2

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.

@jhflemos jhflemos added bug This issue describes a defect or unexpected behavior carvel triage This issue has not yet been reviewed for validity labels Jul 1, 2024
@carvel-bot carvel-bot added this to Carvel Jul 1, 2024
@praveenrewar
Copy link
Member

@jhflemos kapp treats the config provided to it as the source of truth. If you want to use some value from the existing resource on cluster you can use rebase rules to copy that value from the existing source.

@praveenrewar praveenrewar added discussion This issue is not a bug or feature and a conversation is needed to find an appropriate resolution and removed bug This issue describes a defect or unexpected behavior carvel triage This issue has not yet been reviewed for validity labels Jul 4, 2024
@jhflemos
Copy link
Author

@praveenrewar I don't want to use the existing resource on cluster. I'm updating the manifest, in this case, a Service Account one, and the Kapp command is converting the value to a different one. Let me try to explain better:

My current manifest is:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-name
  labels:
    **github.com/sha-short: "1b85fe5e"**

Note that I have a label called "github.com/sha-short" that represents the git commit sha-short information. I have the value "1b85fe5e" in the above example, right?
When I change my source code and commit it to Git remote repository, the new git commit sha-short will be generated. Let's imagine "934881e3". So the new manifest, and right one, that will be applied to the cluster is:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-name
  labels:
    **github.com/sha-short: "934881e3"**

The point is:
The kapp command is converting that value to "934881000". The wrong manifest is:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-name
  labels:
    **github.com/sha-short: "934881000"**

@praveenrewar
Copy link
Member

@jhflemos Apologies, I misread the issue. I think the string is being treated as a number and during marshaling-unmarshaling the e2 is getting replaced by 00. I will take a closer look at it in sometime but my guess is that it might be a bug in one of the json/yaml libraries that we are using.

As a workaround for now: Would it be possible for you to use the complete sha of the commit? As that would have at least one character and then it should be treated as a string.

@praveenrewar praveenrewar added bug This issue describes a defect or unexpected behavior carvel accepted This issue should be considered for future work and that the triage process has been completed and removed discussion This issue is not a bug or feature and a conversation is needed to find an appropriate resolution labels Jul 11, 2024
@renuy
Copy link
Contributor

renuy commented Jul 12, 2024

related to #967

@renuy renuy moved this to To Triage in Carvel Jul 12, 2024
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 carvel accepted This issue should be considered for future work and that the triage process has been completed
Projects
Status: To Triage
Development

No branches or pull requests

3 participants