Tools » teuthology

Just a few thoughts:

• I'm unsure if we'll need to symlink anything. By default everything is looked for relative to the playbook being ran. I believe this will work even when you aren't running ansible-playbook in the directory where the playbook lives, but not 100% on that. Environment vars might be another good option to tie things together if need be.
• Are we going to provide a way to set your own ansible repo url?
• Will we support using different branches for the ansible repo checkout?
• Will ansible run directly on the teuthology node? I'm assuming so.
• per-job host files sounds perfect. The -i flag can even point at a python file to generate the hosts. I believe it just needs to be executable and return something that looks like a hosts file (json, I believe). Here's an example ansible provides doing this for cobbler integration, https://raw.githubusercontent.com/ansible/ansible/devel/plugins/inventory/cobbler.py
• Are we going to worry about calling ansible playbooks from qa-suite now or just handle that later?

I had to reorder your questions to group concepts together.

Andrew Schoen wrote:

Just a few thoughts:

• I'm unsure if we'll need to symlink anything. By default everything is looked for relative to the playbook being ran. I believe this will work even when you aren't running ansible-playbook in the directory where the playbook lives, but not 100% on that. Environment vars might be another good option to tie things together if need be.

Since we have to generate a hosts file, I believe we'll have to generate the playbook as well. Because of that, the playbook we use will likely be in /tmp and not wherever the roles are defined. I'd like to avoid dealing with things in /etc but I'm not yet sure how to point to the roles location.

• Will ansible run directly on the teuthology node? I'm assuming so.

Yes, it'll run where teuthology is run. It seems better than running it on remotes in parallel.

• per-job host files sounds perfect. The -i flag can even point at a python file to generate the hosts. I believe it just needs to be executable and return something that looks like a hosts file (json, I believe). Here's an example ansible provides doing this for cobbler integration, https://raw.githubusercontent.com/ansible/ansible/devel/plugins/inventory/cobbler.py

Hosts files appear to be INI-style. I've seen the inventory plugins before but I'm not sure if they're helpful here or just unnecessary; it's trivial to dump out hostnames to a tempfile.

• Are we going to worry about calling ansible playbooks from qa-suite now or just handle that later?
• Are we going to provide a way to set your own ansible repo url?
• Will we support using different branches for the ansible repo checkout?

I think one way to handle this would be for the ansible task to take a repo arg and a branch arg. If repo points at a remote URL, we could clone it and select the branch. If it points at a local path we could simply use that, ignoring the branch value.

That way we ought to be able to run sets of plays from different repos and/or branches simply by calling the task multiple times with different arguments.

What I'm not sure about, is how to handle secrets configuration.

Work is ongoing here:
https://github.com/ceph/teuthology/tree/wip-ansible

It's extremely close to being done. I've been spending a lot of time in the last few days polishing rough edges in the dealings between our ansible playbooks and machines that have either been provisioned using our old cobbler profiles and chef, or our new cobbler profiles and nothing at all.

The latter is giving me problems. I first ran into an issue where right out of cobbler the cm user had a uid of 1000, preventing ansible from creating the ubuntu user with that uid. That's fixed on RHEL now but not Ubuntu.

Another issue is the question of how to grant access to machines which have just been provisioned with cobbler. Currently we only have a few keys in the cm user's authorized_keys file. I'm starting to wonder if we should just put everyone's key there...