Xenial doesn't come with Python2 installed
carlalexander opened this issue · 4 comments
Easy to test with debops-task fqdn -m setup
. You get this output:
fqdn | FAILED! => {
"changed": false,
"failed": true,
"module_stderr": "",
"module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
"msg": "MODULE FAILURE",
"parsed": false
}
This seems to be an issue since 15.10, but since I've only used 14.04 until now I never encountered it. It's documented here. Have you encountered this with Debian yet?
For now, I had to run debops-task fqdn -m raw -a "apt-get -y install python2.7"
before using DebOps. I also needed to add this variable to the host variables based on information found here:
ansible_python_interpreter: /usr/bin/python2.7
I'm not quite sure what to change in the playbooks to fix this. Seems we'd need a step with a pre_task
to ensure that python2 is installed. Maybe in the core playbook? The ansible_python_interpreter
variable is harder since you need to set this before you get any information from the host.
Python is installed by the debops.bootstrap
role, which can be used in the cases like this to initalize the host environment for management with Ansible. Check the documentation to see how it can be used. After the host is bootstrapped, the main playbook should work normally.
Right, I forgot about that. But won't this become a generalized issue over time? Or do you always assume bootstrap was run beforehand?
No, in fact debops.bootstrap
is just one of the methods that hosts are prepared to be used by Ansible. Other methods included in DebOps at the moment are:
- prepare a DHCP server, PXE server and Debian Preseed server using
debops.dhcpd
,debops.ipxe
anddebops.preseed
roles to deploy hardware hosts or VMs on your network. This is how I deploy new hosts, and preseeding ensures that they are properly configured, have Python installed, admin account is created, SSH keys are deployed, etc. With this setup I don't usedebops.bootstrap
role at all in normal day to day operations. - use custom scripts/templates to deploy new OpenVZ/LXC containers. These scripts do the same things as the
debops.bootstrap
role and above preseeding infrastructure, preparing the hosts to be managed by Ansible.
Because on the cloud VPS providers you might not have the access to their DHCP server, the debops.bootstrap
role is the last resort to handle the bootstrapping problem. What you could do, is to check if your VPS provider supports cloud-init and prepare the hosts using that. At the moment there's no role for this in DebOps, but the relevant documentation can surely be added if needed.
Digital Ocean supports cloud-init. That said, each DebOps users needs to set that up beforehand. So not super useful here. I'll run some tests with debops.bootstrap
. I might just have to start working on a small cli to merge some of these steps.