You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@flink.apache.org by GitBox <gi...@apache.org> on 2022/03/17 02:12:00 UTC

[GitHub] [flink-kubernetes-operator] wangyang0918 commented on a change in pull request #67: [FLINK-26545] Ingress rules in managed namespace (don't merge)

wangyang0918 commented on a change in pull request #67:
URL: https://github.com/apache/flink-kubernetes-operator/pull/67#discussion_r828672167



##########
File path: helm/flink-operator/templates/ingress.yaml
##########
@@ -17,6 +17,23 @@
 ################################################################################
 ---
 {{- if .Values.ingress.create }}
+{{- if .Values.watchNamespaces }}

Review comment:
       Thanks for sharing the progress. For the owner reference, I am afraid we could not set the owner of all the ingress in different namespaces to the operator deployment. Refer to here[1] for more information.
   
   I am just thinking in a different way. Could we only create one ingress for the operator and let the operator do the HTTP requests redirecting? Benefit from this, we could easily integrate a unified authentication if necessary. I believe hadoop YARN[2] is running in a similar way to proxy the application master UI. 
   
   And maybe we could also consider to provide a webUI for the operator itself in the future, which could greatly lower the bar to use our k8s operator.
   
   
   [1]. https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#OwnerReference
   [2]. https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/WebApplicationProxy.html#:~:text=The%20Web%20Application%20Proxy%20is,web%20based%20attacks%20through%20YARN.




-- 
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: commits-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org