bootstrap command against already-bootstrapped controller results in lost controller

[Ryan Beisner]

Juju 2.2.2 + MAAS 2.2.2: If a user has an existing controller and re-issues a bootstrap command against it, juju forgets about the existing controller.

The MAAS machine housing the Juju controller stays up, but the user can longer interact with the model or the controller using the Juju client.

This likely a high-impact with an unintended and dangerous outcome to users.

jenkins@juju-0d10ff-osci-3:~/temp/charm-test-infra⟫ juju bootstrap --bootstrap-constraints 'arch=ppc64el tags=uosci' --constraints 'arch=ppc64el tags=uosci' --auto-upgrade=false --model-default=juju-configs/model-default.yaml --config=juju-configs/controller-default.yaml --to node-huffman ruxton-maas auto-osci-lb00
Creating Juju controller "auto-osci-lb00" on ruxton-maas
Looking for packaged Juju agent version 2.2.2 for ppc64el
Launching controller instance(s) on ruxton-maas...
ERROR failed to bootstrap model: cannot start bootstrap instance: cannot run instances: cannot run instance: No available machine matches constraints: [('agent_name', ['72b6807d-184d-450a-8cfa-f44ed406b2ba']), ('tags', ['uosci']), ('mem', ['3584']), ('name', ['node-huffman']), ('arch', ['ppc64el'])] (resolved to "arch=ppc64el/generic mem=3584.0 name=node-huffman tags=uosci")
1 jenkins@juju-0d10ff-osci-3:~/temp/charm-test-infra⟫

...then:

ERROR No controllers registered.

Please either create a new controller using "juju bootstrap" or connect to
another controller that you have been given access to using "juju register".

[Tim Penhey (thumper)]

It seems that bootstrap needs a sanity check against the controller name already existing.

[Eric Claude Jones (ecjones)]

Issuing a bootstrap command against an existing controller results in juju producing an error stating that the controller already exists. I cannot reproduce the issue. I've tried the issue with both maas and LXD providers.

[John A Meinel (jameinel)]

This looks more like bootstrap failing to provision the machine is destroying the known controllers.yaml file. I'm wondering if they're doing something funny with JUJU_HOME/JUJU_DATA ?

I don't know if ppc64el has anything to do with this, but for now I don't think we can progress without more information.

[Heather Lanigan (hmlanigan)]

Looks like this has been resolved over the years:

$ juju bootstrap localhost monday
Creating Juju controller "monday" on localhost/localhost
Looking for packaged Juju agent version 2.9.17 for amd64
No packaged binary found, preparing local Juju agent binary
...
Bootstrap complete, controller "monday" is now available
Controller machines are in the "controller" model
Initial model "default" added
$ juju bootstrap localhost monday
ERROR controller "monday" already exists