Should charms that use an ingress (kubeflow-dashboard, katib-ui, etc) *require* that ingress to function?

[ca-scribner]

Context

All dashboards (and some other charms, such as envoy) provided in Charmed Kubeflow are exposed through the ingress via istio-pilot's ingress relation. Should these charms enforce that an ingress relation is established (and go to Blocked if the ingress is missing)?

There's a good argument for both choices:

• Arguments for not requiring the ingress:
  • These dashboards do not require an ingress to function (you could browse directly to their ClusterIP without deploying istio)
  • It can be useful to have these charms function without ingresses during testing (that way we don't need istio-pilot in every dashboard test)
• Arguments for requiring the ingress:
  • the Charmed Kubeflow product itself does require these ingress relations to function properly (otherwise users cannot reach the dashboards). Requiring ingresses would make it easier to spot this misconfiguration

A compromise could be adding a debug or ignore-ingress config value in these charms. By default this config could tell the charm to always require ingresses, but if we set this special flag during testing we could ignore the ingress requirement.

What needs to get done

1. decide if we should change anything, and if so implement that change in all our dashboards/charms that need an ingress

Definition of Done

See above

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5477.

This message was autogenerated