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

Support chart installation to an existing namespace #34

Closed
jlegrone opened this issue Oct 11, 2018 · 6 comments
Closed

Support chart installation to an existing namespace #34

jlegrone opened this issue Oct 11, 2018 · 6 comments
Assignees

Comments

@jlegrone
Copy link
Member

I am working with an organization that runs a dedicated tiller instance for each set of namespaces owned by a given business unit. None of these tiller instances have cluster-admin permissions, nor can they create/delete arbitrary namespaces. Teams may also maintain their own chart repositories.

Specifying an existing namespace for chart installation would allow teams to consume this library in a more distributed and self-service manner, without the need for a dedicated cluster or access to a more highly privileged tiller instance.

@unguiculus
Copy link
Member

The tool purposely installs charts into newly created namespaces that are deleted afterwards. If you don't want this why don't you just helm install the chart directly?

@jlegrone
Copy link
Member Author

@unguiculus that's what I'm doing right now, however that means that I'm also separately implementing functionality around git diffs and picking up on values files in the ci subdirectory.

I realize that chart-testing originated just to suit the requirements of helm/charts, but enabling the use of namespaced privileges as described here would allow many more teams to leverage the library.

@jlegrone
Copy link
Member Author

Ah, I do see now that chartlib::print_pod_details_and_logs just looks for all pods in the target namespace, so this would be a bigger change than I initially thought. If this feature request is approved, I could take a look at implementing this after the golang rewrite is merged.

@sonnysideup
Copy link
Contributor

v2.0.0 is all written in Go. 😄

@jlegrone
Copy link
Member Author

Now that ct is go get-able another use case this would help support is local invocation of chart tests by unprivileged users.

@mattfarina
Copy link
Collaborator

@unguiculus If I understand what you're saying, it's that someone who needs to install in an existing namespace should create a script that...

  1. Installs and waits for all the things to come up
  2. Run helm test on it
  3. If they use ci values implement that
  4. Deal with the results

I know we have some lessons learned from these that others may not have, too. For example, the way we wait for deployments in addition to helm waiting.

Would it be better to implement it here, for someone else to come up with a tool that does it, or others to do it as they need?

unguiculus pushed a commit that referenced this issue Dec 14, 2018
This PR adds two flags to the `install` command: `namespace` and `release-label`. If `namespace` is specified, releases will target that namespace and `release-label` will be used to select deployments and pods for readiness and reading log output.

Fixes #34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants