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

Selectively override ownership while using --dangerous-override-ownership-of-existing-resources #993

Open
100mik opened this issue Aug 1, 2024 · 1 comment · Fixed by #996
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

Comments

@100mik
Copy link
Contributor

100mik commented Aug 1, 2024

Describe the problem/challenge you have
I want my kapp app to snatch ownership from existing resources belonging to another app.
However, I only want this to happen if the resource belongs to specific apps.

Describe the solution you'd like
i would like to able to pick which kapp apps I snatch ownership from. Probably by using a "filter-in" filter.
For example. kapp deploy --ownership-override-allowed-apps "oldapp,olderapp" --dangerous-override-ownership-of-existing-resources.

Anything else you would like to add:
We will run into a few limitations here.
First, as of today we cannot easily search for an "app name" if I know the app ID on a resource, without listing all the apps.
Secondly, to avoid privilege escalations, for the time being we will only be able to use this filter for apps in the same namespace.


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.

@100mik 100mik added enhancement This issue is a feature request carvel triage This issue has not yet been reviewed for validity carvel accepted This issue should be considered for future work and that the triage process has been completed and removed carvel triage This issue has not yet been reviewed for validity labels Aug 1, 2024
@renuy
Copy link
Contributor

renuy commented Aug 14, 2024

Recommended to do a no-op delete for the first app.
This should be a dangerous flag.

@renuy renuy reopened this Aug 14, 2024
@github-actions github-actions bot added the carvel triage This issue has not yet been reviewed for validity label Aug 14, 2024
@renuy renuy removed the carvel triage This issue has not yet been reviewed for validity label Aug 14, 2024
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
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

2 participants