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

Added includeClassAnno as a workaround for cert-manager v1.14.5 #2268

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

pertsevds
Copy link

Closes #2267 and #1570

# This is related to the issues webrecorder/browsertrix#1570 and cert-manager/cert-manager#6184
# This relates to the new `http01.ingress.ingressClassName` solver spec attribute which got introduced in the recent v1.15 cert-manager version.
# Cert-manager v1.15 does not want the fields ingressClassName and class be set at the same time.
includeClassAnno: false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this should be called something else, like useOldClassField instead of includeClassAnno since its not an annotation and its specifically about the old field?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So. Should I change it to useOldClassField or what should be a better name for it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's change it to that if you don't mind and then can merge

# This is related to the issues webrecorder/browsertrix#1570 and cert-manager/cert-manager#6184
# This relates to the new `http01.ingress.ingressClassName` solver spec attribute which got introduced in the recent v1.15 cert-manager version.
# Cert-manager v1.15 does not want the fields ingressClassName and class be set at the same time.
includeClassAnno: false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
includeClassAnno: false
useOldClassField: false

@@ -102,7 +102,9 @@ spec:
- http01:
ingress:
ingressClassName: {{ .Values.ingress_class | default "nginx" }}
{{- if .Values.ingress.includeClassAnno }}
Copy link
Member

@ikreymer ikreymer Jan 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
{{- if .Values.ingress.includeClassAnno }}
{{- if .Values.ingress.useOldClassField }}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, seems like this should be an if / else, using ingressClassName only if useOldClassField is not set?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

flowchart TD
    A[Start] --> B
    B{useOldClassField is set}
    B -->|No| C['class:' will not be rendered]
    B -->|Yes| D
    D{useOldClassField is true}
    D -->|No| C['class:' will not be rendered]
    D -->|Yes| F
    F{ingress_class is set}
    F -->|No| G[ingress_class: nginx,<br>class: nginx]
    F -->|Yes, some string| H[ingress_class: some string,<br>class: some string]
Loading

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I see now.
Right now everyone have a config without useOldClassField and after this update they will have their class: option removed.
Right?

So. Should we name this option useNewClassField instead?

Copy link
Member

@ikreymer ikreymer Jan 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think the old class value is for the annotation, which is now obsolete, so can default it to off.
I'm surprised that this worked before, as this check seems to be here for a while:
https://github.com/cert-manager/cert-manager/blame/b96e0af16d197f021904b11066d6307504524f6f/pkg/issuer/acme/http/ingress.go#L159

Elsewhere, we already use ingressClassName so I think that should be the default, and only use the old class if the useOldClassField is set.

Maybe useOldClassAnnotation is more clear even. It was deprecated a while ago now (1.18): https://kubernetes.io/docs/concepts/services-networking/ingress/#deprecated-annotation

Perhaps the only reason to keep it is for GKE, which still requires it: https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#controller_summary

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably to be consistent, we should update the other two ingressClassName to also only be set if useOldClassAnnotation is false, which will be default, otherwise set kubernetes.io/ingress.class
here: https://github.com/webrecorder/browsertrix/blob/main/chart/templates/ingress.yaml#L24
and https://github.com/webrecorder/browsertrix/blob/main/chart/templates/ingress.yaml#L65

@ikreymer
Copy link
Member

ikreymer commented Jan 9, 2025

If you can update soon, we can add this to next 1.13.x release, otherwise will need to wait till 1.14.0

@pertsevds
Copy link
Author

Updated.

@pertsevds
Copy link
Author

If you can update soon, we can add this to next 1.13.x release, otherwise will need to wait till 1.14.0

Maybe it's better to merge it to 1.14.0 as it's a new parameter in the configuration?

@pertsevds pertsevds force-pushed the main branch 2 times, most recently from 1cd62ac to 9b70c77 Compare January 9, 2025 08:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants