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

Allow overriding the metadata.name field in Helm chart for Deployment #574

Open
bderrly opened this issue Feb 23, 2022 · 1 comment
Open

Comments

@bderrly
Copy link
Contributor

bderrly commented Feb 23, 2022

I am using a custom Helm chart which includes this humio-operator Helm chart as a dependency. The Deployment name here is an unfortunate choice as the term humio is used all over the place including both the name of the chart I am using and possibly the Helm release name.

I would like to see the option to override the name of the Deployment (or even hard code it to humio-operator though this is not as flexible and will cause churn for already deployed installations).

@bderrly
Copy link
Contributor Author

bderrly commented Mar 2, 2022

This came about as a result of running the humio-operator in the same kubernetes namespace where the HumioCluster was configured to run as well. The HumioCluster CR is part of an internal Helm chart. The name of the release was humio which caused naming conflicts with the resources applied by the operator. I am going to run the operator in a separate namespace which should keep this from being an issue for me going forward but it is still something that should be considered to be a good citizen in the ecosystem. In my (albeit limited thus far) experience with Helm charts many groups allow overriding the name.

SaaldjorMike added a commit that referenced this issue Mar 3, 2022
The main change here is to better generate resource names for the
resources created by installing the Helm chart.

This also removes the unnecessary single quote characters around values
in the YAML files, which makes syntax highlighting slightly better for
some editors.

Ideally we'd also change it so that the resource labels would use the
names that can now be overridden, but I'm leaving that out for now.
This also removes the `OPERATOR_NAME` environment variable from the
Deployment resource as we don't use it at all, but perhaps we should
later consider adding it back again and populating it e.g. `fullname`
such that any resources created by this operator installation would
create and only touch resources that it itself installed. This may make
it easier for us to better support running multiple operators on the
same Kubernetes cluster.

Fixes: #574
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

Successfully merging a pull request may close this issue.

1 participant