-
Notifications
You must be signed in to change notification settings - Fork 39
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
patch/consistent-naming-ingressClassName #278
base: main
Are you sure you want to change the base?
Conversation
Make ingress.className to ingressClassName to be consistent with ingress.yaml file
Make ingress.className to ingressClassName to be consistent with ingress.yaml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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:
- Update
ingress.yaml
to use.Values.ingress.className
. - Update
ingress-grpc.yaml
to use.Values.grpcIngress.className
. - Update NOTES.txt to fail if
.Values.ingressClassName
is set.
Thanks for the feedback, I'd be glad to make these changes. |
Revert change to ingress-beta.yaml
Update ingress-grpc based on PR feedback
Update based on PR feedback
Fail if ingressClassName is set, per PR comment
@zenon-was-here Can you also add className with an empty string value to both the ingress and grpcIngress sections in the values.yaml |
Add empty string `className:` fields to ingress and grpcIngress values
@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. |
@TylerHelmuth , understood, thanks for the feedback |
@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. |
Prepares an "internal" release of the chart for us to test Refinery 3.0.0. >⚠️ We do not recommend any customer use this version of the chart and we do not support it. Changes: - The commits from #278 (thanks @zenon-was-here!) - Updated default refinery configuration - Updated resource values - A new Statefulset Redis deployment option --------- Co-authored-by: zenon-was-here <[email protected]>
Which problem is this PR solving?
The
ingress-beta
andingress-grpc
Helm templates use one naming convention for an Ingress Class Name:ingress.className
, whereas theingress
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 theingress:
block in the values, which is unintuitive.Short description of the changes
Changes the
ingress-beta.yaml
andingress-grpc.yaml
ingress.className
toingressClassName
to be consistent withingress.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.