Can't bootstrap a Juju controller

I’m trying to deploy Openstack on several MAAS nodes using Juju, following the instructions in the Charm Deployment Guide on the Openstack site. I have 5 nodes commissioned, and I’m to the point of creating the Juju controller. I have one of the nodes tagged with ‘juju’, and I’m using this command:

$ juju bootstrap --bootstrap-series=jammy --constraints tags=juju maas-one maas-controller
Creating Juju controller "maas-controller" on maas-one/default
Looking for packaged Juju agent version 2.9.38 for amd64
Located Juju agent version 2.9.38-ubuntu-amd64 at https://streams.canonical.com/juju/tools/agent/2.9.38/juju-2.9.38-linux-amd64.tgz
Launching controller instance(s) on maas-one/default...
- c4ww6f (arch=amd64 mem=258G cores=48)
Installing Juju agent on bootstrap instance
Fetching Juju Dashboard 0.8.1

I can see the node boot up on my MAAS web site. It sits there for about 15 minutes, and then it turns off and I get this error in my Terminal window:

ERROR failed to bootstrap model: bootstrap instance started but did not change to Deployed state: instance "c4ww6f" is started but not deployed

Any ideas?

Try deploying node c4ww6f directly from the MAAS web UI (remove Juju from the equation) and look at the logs the web UI provides. You can also look at the logs on the MAAS server itself.

Sorry, I got pulled away on another project. I’m trying this again, with the Openstack deployment instructions for Zed. I got to the point of bootstrapping again, and it sat for a long time (maybe 45 minutes) at “Running machine configuration script…”. I read back over some comments on a MAAS thread, and decided to try a newer version of juju as someone suggested, so I hit control-c and got an error:

$ juju bootstrap --bootstrap-series=jammy --constraints tags=juju maas-cloud maas-controller

Creating Juju controller "maas-controller" on maas-cloud/default
Looking for packaged Juju agent version 2.9.42 for amd64
Located Juju agent version 2.9.42-ubuntu-amd64 at https://streams.canonical.com/juju/tools/agent/2.9.42/juju-2.9.42-linux-amd64.tgz
Launching controller instance(s) on maas-cloud/default...
    - kgywsr (arch=amd64 mem=194G cores=16)
Installing Juju agent on bootstrap instance
Fetching Juju Dashboard 0.8.1
Waiting for address
Attempting to connect to 10.63.20.4:22
Connected to 10.63.20.4
Running machine configuration script...
^CERROR failed to bootstrap model: subprocess encountered error code 255

So I removed maas-cloud, updated juju from 3.1/stable, and tried again. It still seemed to be stuck after 30 minutes, so I again hit control-c. This time, no error, and it seems to think it finished:

$ juju bootstrap --bootstrap-series=jammy --constraints tags=juju maas-cloud maas-controller
Creating Juju controller "maas-controller" on maas-cloud/default
Looking for packaged Juju agent version 3.1.2 for amd64
Located Juju agent version 3.1.2-ubuntu-amd64 at https://streams.canonical.com/juju/tools/agent/3.1.2/juju-3.1.2-linux-amd64.tgz
Launching controller instance(s) on maas-cloud/default...
- kgywsr (arch=amd64 mem=194G cores=16)
Installing Juju agent on bootstrap instance
Waiting for address
Attempting to connect to 10.63.20.5:22
Connected to 10.63.20.5
Running machine configuration script...
^CBootstrap agent now started
Contacting Juju controller at 10.63.20.5 to verify accessibility...

Now you can run
    juju add-model <model-name>
to create a new model to deploy workloads.

So it thinks it finished, and the controller shows that it’s running:

$ juju controllers
Use --refresh option with this command to see the latest information.

Controller        Model  User   Access     Cloud/Region        Models  Nodes    HA  Version
maas-controller*  -      admin  superuser  maas-cloud/default       1      1  none  3.1.2  

But “juju add-model --config default-series=jammy openstack” just sits there for as long as I let it.

Any ideas?

After a long while, the add-model attempt failed. Not that I was expecting it to work:

$ juju add-model --config default-series=jammy openstack

ERROR opening API connection: unable to connect to API: dial tcp 10.63.20.5:17070: connect: connection refused

i have the same problems to yours. it’s been a year, have you got it solved? would you mind sharing it with me?

cheers,

I did work it out, but it’s been a year, and I can’t remember exactly what I did. I think it had something to do with which network ports were being used for PXE booting versus “regular” network access, but I’m not sure.

Sorry, I should have been better about following up on this topic, since I’m the one that opened it.