RESOLVED - Failed to bootstrap model: cannot start bootstrap instance

I’ve created a mini virtual lab where have implemented on a host a virtual environment with KVM and used virt-manager to create 2 VM for Maas and Juju. Both the VM are right and that one for Juju is in ready status on Maas.

During the bootstrap of a virtual node via Juju command:

> $:juju bootstrap maas-cloud maas-cloud-controller --to ulab-juju-controller --debug

the result has been that:

… juju.cmd.juju.commands bootstrap.go:778 failed to bootstrap model: cannot start bootstrap instance: failed to acquire node: No available machine matches constraints: [(‘agent_name’, [‘d6969bb2-a7f5-4666-8039-7a5655cbcc0c’]), (‘mem’, [‘3584’]), (‘name’, [‘ulab-juju-controller.maas’])] (resolved to “mem=3584.0 name=ulab-juju-controller.maas”)

considered that I’ve already created a new cloud and adding a credential with:

$: juju add-cloud and $: juju add-credential maas-cloud

someone can help me? thanks in advance.

I try to run this command without indicate the node

> $: juju bootstrap maas-cloud maas-controller --debug

and the result is different, the bootstrap of the node is started but on another one…at this point which is the problem?



at the end the juju controller has been deployed.

I’ve also tried to leave and recreate the same node as the first case on virt-manager, but with the same command the error is that, both VMs are egual.

failed to bootstrap model: cannot start bootstrap instance in any availability zone (Juju, Maas, Openstack, default)

someone can explain me why? thanks in advance.

By default, juju asks for a controller machine with 3.5GB of memory. Your node in MAAS is listed as having only 1.9GB of memory. You can override the memory constraint with bootstrap constraints:

juju bootstrap --to ulab-juju-controller --bootstrap-constraints mem=1.5GB

should allow it to work.

1 Like

thanks Jame,
I’ve tried to create a new VM increased that to 4GB but the issue has been always the same,

using your command obtained that, while avoiding the use of “–to” the bootstrap is right.

I’ve tried to make a test.
After I’ve created a model (prometheus) and deployed a charm, checking its own status I’ve noted that the deploy checks the models present until it found the new one and complete the deploy of charm. Look that ,

$:juju status
Model       Controller             Cloud/Region        Version  SLA          Timestamp
prometheus  maas-cloud-controller  maas-cloud/default  2.7.3    unsupported  22:13:01Z

App          Version  Status  Scale  Charm        Store       Rev  OS      Notes
prometheus2           active      1  prometheus2  jujucharms   14  ubuntu  

Unit            Workload  Agent  Machine  Public address  Ports               Message
prometheus2/0*  active    idle   0        10.0.0.35       9090/tcp,12321/tcp  Ready

Machine  State    DNS        Inst id            Series  AZ          Message
0        started  10.0.0.35  prometheus-server  bionic  monitoring  Deployed