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

Provide a first-class API (as part of App CR status) for discovering deployed resources by App CR #430

Open
antgamdia opened this issue Nov 25, 2021 · 1 comment
Labels
carvel-accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.

Comments

@antgamdia
Copy link

What steps did you take:

  1. Create a PackageInstall via kubectl (not using kapp deploy, I mean)
  2. Get the generated App via kubectl, kubectl get app my-app -oyaml

What happened:

The App does not have any labels/annotations.

What did you expect:

I would have expected this App CR to have something like:

  labels:
    kapp.k14s.io/app: "1637859835366892605"

Anything else you would like to add:

This problem has been discussed at this Carvel community channel thread and there is a temporary workaround: get the ConfigMap whose name is <appname>-ctrl and get from the Data["spec"] the key labelValue.

The motivation main motivation for having this annotation exposed by the App CR is for other clients (like, in my case, the Kubeapps project) to have bidirectional traceability of the resources created as a consequence of an App CR (regardless they're using Kapp or just plain kubectl calls).

Particulary, Kubeapps needs this to display to the users which Kubernetes resources are part of an installation.
Some examples and demo video on the Carvel bundles support in Kubeapps: vmware-tanzu/kubeapps#3816

Environment:

  • kapp Controller version (execute kubectl get deployment -n kapp-controller kapp-controller -o yaml and the annotation is kbld.k14s.io/images):
        - Path: /Users/dhelfand/go/src/github.com/vmware-tanzu/carvel-kapp-controller
          Type: local
        - Dirty: false
          RemoteURL: https://github.com/vmware-tanzu/carvel-kapp-controller
          SHA: 8167469ad3d7c61ce1d170e0f809b437308ce070
          Tags:
          - v0.30.0
  • Kubernetes version (use kubectl version)
- Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.4", GitCommit:"b695d79d4f967c403a96986f1750a35eb75e75f1", GitTreeState:"clean", BuildDate:"2021-11-17T15:48:33Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-21T23:01:33Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/amd64"}

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.

@antgamdia antgamdia added bug This issue describes a defect or unexpected behavior carvel-triage This issue has not yet been reviewed for validity labels Nov 25, 2021
@cppforlife cppforlife changed the title App CRs not created with kapp are not getting any labels Provide a first-class API (as part of App CR status) for discovering deployed resources by App CR Nov 26, 2021
@danielhelfand danielhelfand added carvel-accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request and removed bug This issue describes a defect or unexpected behavior carvel-triage This issue has not yet been reviewed for validity labels Nov 29, 2021
@danielhelfand
Copy link
Contributor

Thanks for this @antgamdia. I think adding this via the status for the App CR makes sense. This could then be also shared with PackageInstalls/PackageRepositories. It may even be an interesting way to track which Package CRs are part of a PackageRepository as documented in #124.

@danielhelfand danielhelfand added the priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. label Jan 31, 2022
@aaronshurley aaronshurley moved this to To Triage in Carvel Aug 18, 2022
@github-project-automation github-project-automation bot moved this to To Triage in Carvel Feb 14, 2023
@neil-hickey neil-hickey moved this from To Triage to Unprioritized in Carvel Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
carvel-accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.
Projects
Status: Unprioritized
Development

No branches or pull requests

2 participants