On 6/15/14 12:06 PM, Monty Taylor wrote:
Hey all,
I spoke to a few people about this on IRC, and I think it's just barely
not crazy enough to commit it to email.
Basically, I've been doing a little bit of hacking on ansible playbooks
for some of the little sysadmin tasks we have which aren't really
puppet-sensible. As part of that, I wrote this:
https://review.openstack.org/#/c/100066/2/modules/openstack_project/files/ansible/run_mirror.yaml
Which looks remarkably like this:
http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/jenkins_job_builder/config/macros.yaml#n288
It would be even more similar if I redid the body of that playbook as a
"role" - which would remove the hosts and give it a name.
It got me thinking - as we're starting to think about how jjb and
turbo-hipster interact, what if we brainstormed for a bit about whether
or not there are ways to either join forces with the ansible folks, or
at least to steal from them if they don't like us.
At the end of the day, jjb and ansible are both trying to simply
describe sequences of tasks to run in places, and separate out the
definition of the tasks from the definition of the orchestration of
those tasks.
So what if it was possible to take the same chunk of yaml, pass it to
ansible for one-off direct execution against a host or hosts, or pass it
to jjb to get it exploded into jenkins xml? Ansible can also do local
exec of rolls/playbooks, which is a thing we want out of turbo-hipster
(we don't have to use ansible itself for that - but otoh, if there is
already a thing that can read the yaml and execute things locally and
that thing is python - then win!)
Now - on the other hand, they're close, but they're not perfectly
aligned, so we'd have to figure out what we'd want to do about that.
Anyway - not urgent - just food for thought.
Monty
_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Hey,
I'm not very familiar with Ansible but I think one of the tricky parts
will be expanding the job definitions from the templates, groups and
projects like JJB currently does. Perhaps JJB continues to do that
expansion but all JJB does is execute Ansible?
This got me to thinking, what if we had agentless job runners. For
example, zuul could use the ansible playbooks to run the jobs itself. It
would likely do this through zuul-workers so it would scale, but it
would remove any complexity for job runners such as Jenkins or
Turbo-Hipster.
Further to that, we could also look at merging zuul's layout.yaml and
JJB's job definitions into one set of configs. For each job we could
define which projects and pipelines it triggers on in the jjb format
which zuul then interprets, builds the entire list of jobs and then uses
ansible to run the playbooks. This would reduce the extra entry of
defining jobs in jjb as well as zuul.
To do this though we would need some kind of integration between jjb and
ansible. Then integration of whatever that is with zuul.
I'm just thinking out loud though.
Cheers,
Josh
--
Rackspace Australia
_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
