Failure to 'juju add-model' silently installs to a subtly broken model

[Jonathan Hall]

Overview:

When configuring juju for k8s, failure to `juju add-model` doesn't prevent app installation, but instead installs to a model called `controller`, and in the same k8s namespace as the controller.

To reproduce:

    $ juju version
    2.9-rc6-genericlinux-amd64

    $ juju add-k8s gke
    $ juju bootstrap gke
    $ deploy cs:~postgresql-charmers/postgresql-k8s postgresql
    $ juju status
    Model Controller Cloud/Region Version SLA Timestamp
    controller gke-us-central1 gke/us-central1 2.9-rc6 unsupported 12:19:36+01:00

    App Version Status Scale Charm Store Rev OS Address Message
    postgresql waiting 0/1 postgresql-k8s charmstore 8 kubernetes installing agent

    Unit Workload Agent Address Ports Message
    postgresql/0* waiting allocating agent initializing

    $ kubectl get pods -A
    NAMESPACE NAME READY STATUS RESTARTS AGE
    controller-gke-us-central1 controller-0 2/2 Running 2 4m33s
    controller-gke-us-central1 modeloperator-56d595f89-6ffrw 1/1 Running 0 3m21s
    controller-gke-us-central1 postgresql-operator-0 1/1 Running 0 35s
    kube-system event-exporter-gke-666b7ffbf7-dgx68 2/2 Running 0 11m
    < ... snip ... >

What I would expect instead:

1. An error from `juju deploy` telling me that there is no model configured, so I need to do that first.
2. Alternately, if a default model makes sense, it probably needs a better name than `controller`, or at the very least, it should deploy applications to a `controller` namespace, to be consistent.

[Ian Booth (wallyworld)]

The controller model is a legitimate model which holds to core Juju management infrastructure, but can host applications if desired. In Juju 2 we automatically create a "default" model when bootstrapping but are moving away from this behaviour for Juju 3 so that it behaves in the same way as it does now for k8s, ie do not create an arbitrary model. The user is expected to create whatever model they want to deploy things to explicitly after bootstrap. We got lots of feedback that the current (non k8s) behaviour is confusing and/or undesired. After bootstrap finishes, there is messaging (on k8s) telling the user they should add-model, so doesn't that cover point 1?

The reason the namespace is not just "controller" is because the cluster can be shared by several users and they can't all use the namespace "controller", so we need to disambiguate with the name of the controller.

[Jonathan Hall (flimzy)]

Interesting. Thanks for the info!

> After bootstrap finishes, there is messaging (on k8s) telling the user they should add-model, so doesn't that cover point 1?

Perhaps. It's easy to overlook (as I did). When I discovered my error, I was surprised that juju continued. Perhaps the messaging can be expanded to mention the default behavior?

[John A Meinel (jameinel)]

I would leave the client without a default model selected. So that just
'juju deploy' would fail. While they might be able to 'juju switch' to the
controller model, it shouldn't default to deploying there.

On Wed, Feb 3, 2021 at 4:10 PM Ian Booth <email address hidden> wrote:

> The controller model is a legitimate model which holds to core Juju
> management infrastructure, but can host applications if desired. In Juju
> 2 we automatically create a "default" model when bootstrapping but are
> moving away from this behaviour for Juju 3 so that it behaves in the
> same way as it does now for k8s, ie do not create an arbitrary model.
> The user is expected to create whatever model they want to deploy
> things to explicitly after bootstrap. We got lots of feedback that the
> current (non k8s) behaviour is confusing and/or undesired. After
> bootstrap finishes, there is messaging (on k8s) telling the user they
> should add-model, so doesn't that cover point 1?
>
> The reason the namespace is not just "controller" is because the cluster
> can be shared by several users and they can't all use the namespace
> "controller", so we need to disambiguate with the name of the
> controller.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1914395
>
> Title:
> Failure to 'juju add-model' silently installs to a subtly broken model
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1914395/+subscriptions
>

[Joseph Phillips (manadart)]

Having no current model designated client-side is the best approach here.