Skip to content

Support a custom name for all resources in Helm #4469

Open
@coolbry95

Description

@coolbry95

Is your feature request related to a problem? Please describe.
Having each resource have a way to name it explicitly without workarounds. We need most resources named 'nginx-ingress' because this is how an older version of the helm chart worked. There are work arounds in the latest helm chart 1.0.0 to be able to do this. Now we are running into an issue cluster wide resources like ClusterRole because we deploy 'nginx-ingress' multiple times per cluster.

An example of workarounds.
79a3eb9

Currently we need to do something like this to get most resources named 'nginx-ingress'.

nginx-ingress:
  fullnameOverride: "nginx-ingress"
  serviceNameOverride: "nginx-ingress"
  controller:
    enableSnippets: true
    name: ""

Describe the solution you'd like
I would like each resource to have a name parameter that will explicitly name the resource.

Maybe this would look like for each resource but only using rbac as an example.

controller:
   rbac:
      name: "name here"

Name shows up in a few places but the behavior of name might be different for each resource.
https://github.com/nginxinc/kubernetes-ingress/blob/v3.3.0/deployments/helm-chart/values.yaml#L3
https://github.com/nginxinc/kubernetes-ingress/blob/v3.3.0/deployments/helm-chart/values.yaml#L233
https://github.com/nginxinc/kubernetes-ingress/blob/v3.3.0/deployments/helm-chart/values.yaml#L384

Additionally there are a few configurations that are no documented.
.Values.nameOverride
.Values.fullnameOverride
.Values.serviceNameOverride

An override for each resource would also be acceptable if that is the name of the resource explicitly.

Describe alternatives you've considered
Vendor the chart and make the changes needed ourselves or change how we do our deployments so that this is not an issue.
We moved away from vendoring and making the changes we have needed upstream. Vendoring makes our lives harder and makes it less likely we will push our changes upstream.
Changing out deployments is not really an option.

Additional context

Metadata

Metadata

Assignees

No one assigned

    Labels

    good first issueIssues identified as good for first-time contributorsproposalAn issue that proposes a feature request

    Type

    No type

    Projects

    Status

    Todo ☑

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions