You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When deploying the MLFlow additional access point to MLFlow is created.
Why do we expose this? Should we not use relations to Istio/pilot and ingress gateway to expose MLFlow, especially since MLFlow is open to the public by default? When used with Charmed Kubeflow the DEX is used to provide the authentication.
I think we've treated the mlflow charm as something that could be deployed with kubeflow or standalone, rather than something that had to be with kubeflow. But it would make more sense to have configuration options to only expose what is needed based on the setup chosen
When deploying the MLFlow additional access point to MLFlow is created.
Why do we expose this? Should we not use relations to Istio/pilot and ingress gateway to expose MLFlow, especially since MLFlow is open to the public by default? When used with Charmed Kubeflow the DEX is used to provide the authentication.
In code:
mlflow-operator/charms/mlflow-server/src/charm.py
Line 216 in 4bdda5d
The text was updated successfully, but these errors were encountered: