I’ve created a new ENC for ansible that allows it to communicate and get node lists and node vars from The Foreman (http://theforeman.org/) and thought I’d share.
If you don’t know what The Foreman is you can probably disregard this email as Ansible can probably do all of what you need. But, if you’re like me and in an organization that has a lot of time and work-flows built around The Foreman and Puppet this ENC can use that existing data and makes it easy to classify and group your nodes based on any puppet fact.
https://github.com/romeotheriault/foreman-ansible
Cheers,
It would be interesting if you could get Foreman to support ansible facts.
Though that's ansible itself, and the group_by module, so I guess you
don't need it in that case, kind of 
--Michael
It would be interesting if you could get Foreman to support ansible facts.
Hadn't thought much about that but yeah, I agree that would be
interesting... It's probably not that far off either as there's been some
talk on the foreman list about making it support other CM tools besides
puppet, which would be ideal. I'll kick this idea around some more ...
Though that's ansible itself, and the group_by module, so I guess you
don't need it in that case, kind of
Kind of group_by module is great up to a certain node count, beyond
which ssh'ing into each server and running the 'setup' module starts to
take more time than one would like.
Romeo
There are a couple of callback modules that keep an inventory DB with
facts. If there is a scaling issue it should not be hard to make
setup_localstore? work.
Kind of group_by module is great up to a certain node count, beyond which
ssh'ing into each server and running the 'setup' module starts to take more
time than one would like.
More reason to use fireball, no?. Only SSH to each server once.
See also:
gather_facts: False on plays that don't need to gather facts.
There are a couple of callback modules that keep an inventory DB with
facts.
Good to know, I wasn't aware of these. I'll check them out. Though, we're
not going to be moving away from puppet for "a while" so for my particular
case it makes more sense to make use of our already available "facts"
instead of duplicating them into another place.
If there is a scaling issue it should not be hard to make
setup_localstore? work.
I think that sounds like a great idea.
Actually, nix the setup_xxx, I believe you can just use a inventory
script to do the same.
Agreed, in some cases that'd be a reasonable method. In my case we support
a lot of legacy solaris systems where I'm not really interested in getting
the fireball bits working on them and like I said we already have all the
info we need available in a DB so figured we'd use it.
Not sure I'm following you here.
sorry for late reply, missed this.
Your inventory script can be an executable that returns hosts, groups
and vars dynamically to ansible.