hello dear,
I’ve received this issue during the bootstrap of JUJU controller :
09:11:55 ERROR juju.cmd.juju.commands bootstrap.go:795 failed to bootstrap model: bootstrap instance started but did not change to Deployed state: instance "xh88qk" failed to deploy
the command I’ve always used is that:
$: juju bootstrap --bootstrap-series=focal maas-cloud maas-cloud-controller --debug
any tips, thanks
If you see further up in the error stack, you can see that it can’t failed to find any machines with in the zone “Active Directory”. I’m pretty sure that’s your source of the error.
The particular error that it is mentioning is that MAAS is telling us that we can use machine “xh88qk” but it is failing to get to Deployed state, where we can actually expect it to run software on it.
You could try using “juju bootstrap --keep-broken” which will skip the step where we tear down the machine after we feel it has failed to start. Which would potentially let you ssh to the machine and look at files like /var/log/cloud-init-output.log to see if there was a clear problem while starting the machine.
Looking at your MAAS UI, it looks like there is only a single machine which it could possibly provision. (At least, I think New means it hasn’t finished doing a commissioning step, and Rescue mode probably cannot be provisioned. Leaving only ‘juju-controller.maas’, though that is likely what you want.)
I don’t know if this part is relevant, but it appears you have a
default-space: development
But the juju-controller.maas is only in the Juju space.
Potentially you would want to do:
juju bootstrap ... --model-default default-space=Juju
and/or --bootstrap-config to make sure that the controller is being set up correctly.
I’ve run that
juju bootstrap --keep-broken --bootstrap-series=focal maas-cloud maas-cloud-controller --debug
but same issue debug
--keep-broken isn’t about fixing bootstrap, it is about leaving the machine running so you can SSH in and inspect if there are any messages in /var/log that can help understand what went wrong. And/or see what the status of the machine is in MAAS (did it actually progress from Allocating).
It’s ok about that but after to run the command the VM after that issue is killed and it’s impossible to connect via SSH.
Here is the error on MAAS
So not finding /dev/disk/by-id sounds more like a low level machine issue.
You might try recomissioning the node in MAAS. I believe there is a flag to tell MAAS that it should fully wipe the disk when the node is decommissioned.
There isn’t much that Juju can do here, because MAAS isn’t able to set up the machine to hand it over to Juju for us to do our thing.
At this point it looks more like a MAAS issue that would need to be resolved first.
This problem looks very similar to another one reported a few days ago:
yes it’s the same.
I’ve tried to re-made the lab and that issue is still present with a different name:
20:50:08 ERROR juju.cmd.juju.commands bootstrap.go:795 failed to bootstrap model: bootstrap instance started but did not change to Deployed state: instance "xbdydy" failed to deploy
I’ve found also this, there are other guys have that issue:
also this
I’m trying to make the update of MAAS to 2.8 via snap and I’ll try to rebuild the lab.
Dear guys,
I’ve resolved, after to make the upgrade of MAAS to 2.8 and run the bootstrap of Juju controller the lab is up
Great to hear, please do come and join us over in discourse.maas.io if you have further issues or questions about MAAS.
again the same error, this time I’ve used a clear environment on my lab, the VM are composed by:
1 VM with u20.04 Maas (ver .2.8.2) + Juju (ver. 2.8.1) both installed via snap
1 VM with u20.04 Juju controller
with the command for the bootstrap
$: juju bootstrap --bootstrap-series=focal maas-cloud maas-cloud-controller --debug
here that again
> juju.cmd.juju.commands bootstrap.go:783 failed to bootstrap model: bootstrap instance started but did not change to Deployed state: instance “8epqeq” failed to deploy
So, I open also a new topic on MAAS discourse.
Maybe I’ve resolved changing the default storage in LVM type for the VM on MAAS, the topic is the link above
At this point I don’t know if that issue is a bug or the VMs have to be set via LVM storage.
You are correct setting the disks to LVM allows a vm to complete the deployment. I was following the steps to do a large scale deployment of openstack and ran in to the same issue.
I created a vm for the juju server and it failed to deploy several times i finally stumbled across this thread and as soon as i set the disk to lvm in settings for maas it immediately deployed regardless of if juju was asking or if i tried to manually deploy. I would suspect there is some kind of bug.
I think so too!!!I don’t know if that is a bug or not…we’ve to wait a new release
@riccardo-magrini plz how you set the power type at virsh!
when i try to set it gives me this error:
