It could be several things indeed. So let's go through the generic steps of getting logs from a failed deployment. First let's show how to get access to the different juju environments in play here:
- Landscape environment: where the Autopilot was deployed
- Autopilot environment: the cloud environment created by Autopilot
Taken from Landscape openstack juju management:
To get access to the Landscape juju environment, please run the following from the place where you installed LDS:
# First we need to get to the Landscape juju environment.
# If you used the install-openstack tool, you want to do this first:
# Get an interactive shell with the right ENV sourced on the landscape
# server itself. This gives you access to the Autopilot deployed cloud
# juju environment:
juju ssh landscape/0 sudo 'JUJU_HOME=/var/lib/landscape/juju-homes/`sudo ls -rt /var/lib/landscape/juju-homes/ | tail -1` sudo -u landscape -E bash'
# You should see a lot of openstack services with this command:
At this point, you can poke around the cloud environment. To reach the unit
nova-compute/0, for example, run
juju ssh nova-compute/0.
The data and logs that are useful to debug a stalled deployment are as follows:
/var/log/landscape-server/*.log from the
landscape/0 unit from the Landscape environment. In particular,
/var/log/juju/*.log from the cloud environment bootstrap unit (machine 0, run
juju ssh 0 to reach it from
juju status output from the cloud environment
- how many computers, if any, you have registered in Landscape at the point you decided it stalled. If it's zero, then we need
/var/log/landscape/*.log from any cloud environment unit, like