-
Notifications
You must be signed in to change notification settings - Fork 78
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
feat: add support for multiple hosts and tls configurations in ingress #218
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Marcus Söderberg <[email protected]>
Signed-off-by: Marcus Söderberg <[email protected]>
|
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
Still waiting for review so please keep it open. |
@@ -20,11 +20,16 @@ spec: | |||
{{- if .Values.ingress.className }} | |||
ingressClassName: {{ .Values.ingress.className | quote }} | |||
{{- end }} | |||
{{- if .Values.ingress.tls.enabled }} | |||
{{- if or .Values.ingress.tls.enabled .Values.ingress.extraTls }} |
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.
Is there a reason we're adding the or
condition here? I would have thought just the checking if .Values.ingress.tls.enabled
is enabled should be enough. We have the extraTLS
check below anyways and if you were adding extra TLS, you would already have the .tls.enabled
set to true anyways.
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.
Having the or
condition allows you to enable TLS only for extra hosts (e.g. with item(s) defined in ingress.extraTls
and ingress.tls.enabled: false
). I don't know if that's a use case worth supporting though, so I'm open to change it if that's preferable. If I change it I think it makes sense to move the extraTls
object from ingress.extraTls
to ingress.tls.extraTls
. Let me know what you think!
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.
Yep, let's go with the ingress.extraTls
to ingress.tls.extraTls
, perhaps keeping the use case simple at the moment with the most likely scenario is best for now. If it's needed in future we can always change to add TLS only for extra hosts.
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.
Having the or condition allows you to enable TLS only for extra hosts (e.g. with item(s) defined in ingress.extraTls and ingress.tls.enabled: false). I don't know if that's a use case worth supporting though, so I'm open to change it if that's preferable. If I change it I think it makes sense to move the extraTls object from ingress.extraTls to ingress.tls.extraTls. Let me know what you think!
good catch!
Yep, let's go with the ingress.extraTls to ingress.tls.extraTls
isn't ingress.tls.extraTls
a bit redundant? Looking at other charts ingress.extraTls
seems the way to go, but happy to discuss.
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.
@vinzscam Yep, seems to have my values wrong way around there, good catch!
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.
Thanks for the feedback! I created a PR with the change (remove the or
condition) to this branch just to make sure we're all on the same page: msoderberg#1.
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.
@msoderberg I think the original changes you've got in this PR should be good! We can wait for @vinzscam to confirm that also, but from my perspective, the changes look ok to me.
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
I think this is getting ready for merge. I just need a reply on my comment here: #218 (comment) |
Description of the change
Adds
ingress.extraHosts
andingress.extraTls
which allows you to add extrahost
andtls
items to the generated Ingress resource.Existing or Associated Issue(s)
Additional Information
We run Backstage in EKS and are currently adding a condition annotation in the Ingress to configure the AWS ALB with an extra hostname. The downside with this approach is that we have to specify the AWS ACM certificate ARN:s for the domains (we loose the certificate discovery functionality).
There are other workarounds as well (e.g. using
extraDeploy
to create multiple Ingress resources), but having native support for multiple hosts in the Helm chart would simplify our life a bit.Checklist
Chart.yaml
according to semver.values.yaml
and added to the README.md. The helm-docs utility can be used to generate the necessary content. Usehelm-docs --dry-run
to preview the content.ct lint
command.