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.

Sign up for GitHub

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

Jump to bottom

Ability to set namespace for storing kapp meta configmaps #815

Closed
praveenrewar opened this issue Sep 4, 2023 · 0 comments · Fixed by #814
Closed

Ability to set namespace for storing kapp meta configmaps #815

praveenrewar opened this issue Sep 4, 2023 · 0 comments · Fixed by #814
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

@praveenrewar
Copy link
Member

Describe the problem/challenge you have
I want to set the namespace for storing the kapp metadata configmaps. Currently this is being done via the default namespace from the kubeconfig or by using the -n flag, but both of them set this for all the resources that are created by the app (unless the resources have a metadata.namespace field specified). This requires me to provide kapp with create/update and delete permissions for configmaps in my namespace. I would like to keep these separate so that I can isolate the rbac resources in a different namespace

Describe the solution you'd like
Add a flag --app-namespace in the kapp commands which can be used to specify the namespace to store the kapp meta configmaps.

Anything else you would like to add:
The --app-namespace flag would take precedence over the -n flag, but if --app-namespace is not specified then kapp would behave in the same fashion as it does now, this will ensure that users who are already using kapp won't be impacted.

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.
@praveenrewar praveenrewar added enhancement This issue is a feature request carvel triage This issue has not yet been reviewed for validity labels Sep 4, 2023
@praveenrewar praveenrewar mentioned this issue Sep 4, 2023
Merged
5 tasks
@praveenrewar praveenrewar added 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 Sep 13, 2023
jfmontanaro added a commit to jfmontanaro/carvel that referenced this issue Mar 5, 2024
@jfmontanaro
Use --app-namespace rather than -n for dedicated option in state-name…
7306953 
…space.md

When using a dedicated namespace for state storage, the docs currently suggest specifying this namespace via the `-n` flag. However this can lead to undesirable behaviors, since the app is typically being deployed to a different namespace. In my case, I had a resource where I had neglected to specify the namespace, and it would have ended up getting deployed to the state-storage namespace rather than the same namespace as the rest of the app.

This was discussed in carvel-dev/kapp#815 and fixed in carvel-dev/kapp#814 with the introduction of the `--app-namespace` flag, which controls which is used for state storage independently of the app namespace. However the docs did not reflect this change.

This commit adjusts the documentation to recommend using `--app-namespace` when storing configs in a separate namespace.
This was referenced Mar 5, 2024
Closed
Merged
jfmontanaro added a commit to jfmontanaro/carvel that referenced this issue Mar 12, 2024
@jfmontanaro
Use --app-namespace rather than -n for dedicated option in state-name…
8fe5af9 
…space.md

When using a dedicated namespace for state storage, the docs currently suggest specifying this namespace via the  flag. However this can lead to undesirable behaviors, since the app is typically being deployed to a different namespace. In my case, I had a resource where I had neglected to specify the namespace, and it would have ended up getting deployed to the state-storage namespace rather than the same namespace as the rest of the app.

This was discussed in carvel-dev/kapp#815 and fixed in carvel-dev/kapp#814 with the introduction of the  flag, which controls which is used for state storage independently of the app namespace. However the docs did not reflect this change.

This commit adjusts the documentation to recommend using  when storing configs in a separate namespace.

Signed-off-by: Joseph Montanaro <[email protected]>
100mik pushed a commit to carvel-dev/carvel that referenced this issue Mar 17, 2024
@jfmontanaro @100mik
Use --app-namespace rather than -n for dedicated option in state-name…
347976d 
…space.md

When using a dedicated namespace for state storage, the docs currently suggest specifying this namespace via the  flag. However this can lead to undesirable behaviors, since the app is typically being deployed to a different namespace. In my case, I had a resource where I had neglected to specify the namespace, and it would have ended up getting deployed to the state-storage namespace rather than the same namespace as the rest of the app.

This was discussed in carvel-dev/kapp#815 and fixed in carvel-dev/kapp#814 with the introduction of the  flag, which controls which is used for state storage independently of the app namespace. However the docs did not reflect this change.

This commit adjusts the documentation to recommend using  when storing configs in a separate namespace.

Signed-off-by: Joseph Montanaro <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
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
Carvel
Archived in project
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add --app-namespace flag praveenrewar/kapp
1 participant
@praveenrewar