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:
export JUJU_HOME=~/.cloud-install/juju
juju status
# 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:
juju status
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, job-handler.log
.
/var/log/juju/*.log
from the cloud environment bootstrap unit (machine 0, run juju ssh 0
to reach it from landscape/0
)
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 nova-compute/0
.