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

Add namespace configuration option for kubectl/kustomize #3172

Closed
AndiDog opened this issue Nov 5, 2019 · 6 comments · Fixed by #4374
Closed

Add namespace configuration option for kubectl/kustomize #3172

AndiDog opened this issue Nov 5, 2019 · 6 comments · Fixed by #4374
Labels
area/deploy kind/feature-request priority/p3 agreed that this would be good to have, but no one is available at the moment.

Comments

@AndiDog
Copy link
Contributor

AndiDog commented Nov 5, 2019

Expected behavior

Target deployment namespace should be specifiable in skaffold.yaml, e.g. deploy:kubectl:namespace.

Actual behavior

The helm deployer supports deploying to a certain namespace as specified in skaffold.yaml, but for kubectl/kustomize deployers, that can only be achieved with the environment variable SKAFFOLD_NAMESPACE or -n/--namespace CLI option.

Information

  • Skaffold version: v0.41.0

This is helpful if the namespace depends on the environment, e.g. dev/prod using a different namespace, but the values are still fixed and should therefore not require any special env var or CLI parameter to run a deployment correctly.

Probably somewhat relevant for #915 (similar use case).

@tejal29 tejal29 added the kind/question User question label Nov 7, 2019
@tejal29
Copy link
Member

tejal29 commented Nov 7, 2019

@AndiDog there is a --namespace flag for --deploy

@tejal29 tejal29 closed this as completed Nov 7, 2019
@AndiDog
Copy link
Contributor Author

AndiDog commented Nov 9, 2019

Sorry, a CLI argument is not a solution as I described in the summary. skaffold.yaml is supposed to be the central source of truth, while CLI args and environment variables serve as overrides. Therefore, one needs to be able to specify the default target namespace in that config file, while -n/--namespace/SKAFFOLD_NAMESPACE allow overriding that setting.

Can you please reopen, considering this use case? I'm even eager to implement that – shouldn't be too hard.

@balopat balopat added kind/feature-request and removed kind/question User question labels Nov 21, 2019
@balopat balopat reopened this Nov 21, 2019
@balopat balopat added area/deploy priority/p2 May take a couple of releases labels Nov 21, 2019
@balopat
Copy link
Contributor

balopat commented Nov 26, 2019

I'm open for adding this, and thank you @AndiDog for volunteering to implement it :)

@AndiDog
Copy link
Contributor Author

AndiDog commented Jan 29, 2020

As an update: I've looked into this, but still have to find some more time to see how it can be done – right now, most code uses the run context namespace, and that would need to be overridden/changed by configuration. Any hints welcome.

@tstromberg tstromberg changed the title kubectl/kustomize deployers should have a configuration for default target namespace (like SKAFFOLD_NAMESPACE/-n/--namespace) Add namespace configuration option for kubectl/kustomize Apr 30, 2020
@tstromberg tstromberg added priority/p3 agreed that this would be good to have, but no one is available at the moment. and removed priority/p2 May take a couple of releases labels Apr 30, 2020
@tstromberg
Copy link
Contributor

@AndiDog - Is this still being worked on? Let us know if there is anything in particular we can help with.

@AndiDog
Copy link
Contributor Author

AndiDog commented Apr 30, 2020

I made a start on it, but didn't get it finished yet. Too busy, and was also waiting on another PR. Hopefully I can progress here soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/deploy kind/feature-request priority/p3 agreed that this would be good to have, but no one is available at the moment.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants