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
Flux CLI tool doesn't respect context namespace #3453
Comments
I agree with this report in principle, however I'd like to note as a point of information that this is not a regression. This is how You can use I think it would be very inconvenient for most users if the default |
@kingdonb I can better understand the way most people use flux from your perspective, and what you said makes perfect sense. Perhaps there could be an environment variable for following the current context or not as a compromise? We do keep most resources within flux-system e.g. helmcharts, helmrepos, kustomizations, gitrepos etc., but having helmreleases in the intended namespace makes the most sense for how we interact with flux because if a helmrelease is having issues it's nice to be able to see the helm installation via helm commands to fix it. This is why having context follow would be nice since most of our flux interactions involve working with helmreleases. |
Thanks for that added context,
That sounds like a good compromise! Only, flux already follows the context, it's just namespace that isn't followed. If |
@kingdonb I think FOLLOW or INHERIT make sense. Either that or maybe FLUX_INHERIT_CONTEXT_NAMESPACE. Maybe say CONTEXT instead of CURRENT because the namespace comes from current context. |
The rubyist in me wants every name to be as close to a complete and fully expressive sentence as possible, now it's clear the concept is a bit obscure; I don't think inherit quite captures what we're saying, (and I'm afraid of using big/overloaded words like inherit that somebody may incorrectly infer that this has something to do with object oriented inheritance.)
Not to put the cart in front of the horse either, let's figure out who can contribute the PR for this and whether it could merge, or if there's an even better option I haven't considered, before I spend too much time on what color to paint the bikeshed 🙃 |
@kingdonb honestly I don't really mind what it is called so long as it is documented and I can use it. I was just giving some ideas. I think either of your suggestions works for me. <3 |
I took a stab at implementing this today as this feature might be especially helpful in multi-tenant scenarios where each tenant has their Flux resources in a dedicated Namespace, different from the default of "flux-system". What makes this incredibly hard to do is that the upstream library we use has no (easy) way to determine if the user explicitly requested a certain Namespace or not where in the latter case we would default to "flux-system". There is the Desired order of precedence:
|
Ok, I found a way but it's much more involved than what I have time for right now. If anyone wants to pick my current progress up, here's the commit. |
P.S.: Global variables are a PITA! |
Describe the bug
Say a Kubeconfig has the following block:
When you run flux commands it will not target the namespace your context is currently using. It always targets flux-system unless the namespace flag is specified. For continuity sake between all kubernetes cli tools e.g. kubectl and helm the cli should use namespace context for CLI calls.
Steps to reproduce
Run
flux reconcile hr service
See this error
✗ helmreleases.helm.toolkit.fluxcd.io "service" not found
Run
flux reconcile hr service --namespace service
It works
Expected behavior
flux reconcile hr service
it works
Screenshots and recordings
No response
OS / Distro
Fedora
Flux version
v0.38.2
Flux check
N/A
Git provider
No response
Container Registry provider
No response
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: