patch/consistent-naming-ingressClassName

[zenon-was-here]

Which problem is this PR solving?

The ingress-beta and ingress-grpc Helm templates use one naming convention for an Ingress Class Name: ingress.className, whereas the ingress template uses a different convention: ingressClassName.

The problem solved is to adopt a consistent naming convention. I've opted to the latter one, ingressClassName, as it's used in Kubernetes example docs.

Otherwise, users have unexpected inconsistent behavior when trying to specify the Ingress Class Name for the different ingresses. And, populating the grpcIngress's Ingress Class Name currently would have to happen within the ingress: block in the values, which is unintuitive.

• Closes #N/A

Short description of the changes

Changes the ingress-beta.yaml and ingress-grpc.yaml ingress.className to ingressClassName to be consistent with ingress.yaml and Kubernetes convention.

How to verify that this has the expected result

Specify an ingressClassName in a values.yaml file and dry-run. No tests because it's a minimal change that seems to fit the "small and obvious" acceptance criteria laid out in the lifecycle-and-practices doc.

[TylerHelmuth]

@zenon-was-here thank you for bringing this to our attention. There are actually a couple issues with our use of ingress class name spread out between the files.

First, ingress.yaml uses .Values.ingressClassName. This equates to a root level field in the values.yaml named ingressClassName. But the default values.yaml has an ingress section, which is where all ingress configuration should live. So .Values.ingress.className is the most appropriate.

Second, ingress-grpc.yaml uses .Values.ingress.className, but there is a grpcIngress section in the values.yaml that it should be using.

What I think we should do:

1. Update ingress.yaml to use .Values.ingress.className.
2. Update ingress-grpc.yaml to use .Values.grpcIngress.className.
3. Update NOTES.txt to fail if .Values.ingressClassName is set.

[zenon-was-here]

Thanks for the feedback, I'd be glad to make these changes.

[TylerHelmuth]

@zenon-was-here Can you also add className with an empty string value to both the ingress and grpcIngress sections in the values.yaml

[TylerHelmuth]

@zenon-was-here thanks for making these changes. These are breaking changes, so we'll talking internally about how to handle this. I haven't been able to think yet of a clever way to handle the grpc breaking change.

[zenon-was-here]

@TylerHelmuth , understood, thanks for the feedback

[TylerHelmuth]

@zenon-was-here thanks again for working on this, I am going to integrate your changes into an upcoming v3.0.0 version of the chart.