morhidi commented on a change in pull request #67:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/67#discussion_r827898165
##########
File path: helm/flink-operator/templates/ingress.yaml
##########
@@ -17,6 +17,23 @@
################################################################################
---
{{- if .Values.ingress.create }}
+{{- if .Values.watchNamespaces }}
Review comment:
You're right the all namespace scenario is not covered properly. We
discussed this yesterday with @gyfora and @mbalassi and haven't had the chance
to update the PR yet.
My main motivation behind using the Helm chart for creating the Ingresses
was to use a more predictable/static manner. To my best knowledge Ingresses
require at least an LB address, and a wildcard DNS entry with the current
implementation to work properly, sometimes firewall/NW changes.
So my suggestion for the ingress logic is the following:
- pre-create Ingresses for all watchNamespaces when the Operator is started
(Let's use Java then)
- create Ingresses on the fly whenever a CR is created in a new namespace
- Set the operator deployment as the owner of all Ingresses and never delete
them to avoid dynamic LB generation.
Let me know what you think @wangyang0918
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
