Workflow where knative-serving/eventing spawns new namespaces feels unusual

[ca-scribner]

At present, charmed knative is designed¹ such that:

• the knative-operator charm deploys the upstream knative operator. This operator manages all knative serving/eventing deployments for us
• knative-serving (/knative-eventing) charms deploy/manage an instance of a KnativeServing (/KnativeEventing) CR which is acted upon by the upstream knative operator

The way someone might use these then is by:

juju deploy knative-operators
juju deploy knative-serving --config namespace=some-namespace [...other config]

This would result in the knative-serving charm creating a KnativeServing CR that requests for knative serving to be deployed in the namespace some-namespace, and the upstream knative operator will create this namespace/deploy things.

This pattern feels odd compared to other juju things. Typically, we'd expect applications to work within their models. Would it make more sense to design the knative-serving (/knative-eventing) charms to always ask for an instance within their own namespace, and then deploy them to a separate model? The workflow would then be:

# from kubeflow model
juju deploy knative-operators

juju add-model some-namespace
juju switch some-namespace
juju deploy knative-serving [...other config]  # Note that `--config namespace` is removed

where the result is a knative serving instance in the namespace some-namespace?

This feels more Juju, but might be less practical. We package knative in the kubeflow bundle - can a bundle have multiple models?

Footnotes

1. Charmed Knative design spec ↩