Accessing hostvars in module

Archives Ansible Project
1

Hi all. Deepest apologies if this is documented elsewhere. I have tried and failed so far to find it.

I’m writing a module to take stuff out of host_vars and populate values in cobbler. I’ve found a few references that say it is possible to access host_vars data inside a module if it’s a server-side module, but I haven’t yet found out how I write a module that works like that. I’ve played with making modules in python using the shortcuts and the #<<INCLUDE_ANSIBLE_MODULE_COMMON>> goodies. I also started looking at the template.py module, but that’s not really a module… or is it? Anyway, I’m floundering around trying to figure out how to make a module that is both (a) a server-side module and (b) has access to host_vars and all that goodness. I’ll keep searching, but if anyone knows a writeup or an example module that might help me, a hint would be awesome.

Thanks All!

And thanks for Ansible!
-Dylan

2

Do you mean an ansible module to populate cobbler?

That seems a bit backwards to me (I mean this nicely, having written both, I feel I can kind of say that). It seems more likely to use cobbler as an inventory source for ansible.

Modules don’t get to see hostvars for all the other servers by design – ansible is set up on a principle of least information so you only see what gets passed to each module on remote boxes, thus you don’t “leak” information about other servers they shouldn’t know about.

Thus, it sounds like you just want to pass a parameter to a module, you could that through hostvars if you want, if need be, like so:

modulename: foo asdf={{ hostvars[“other_server.example.com”][“some_other_var”] }}

However because you’re starting off talking about populating Cobbler from Ansible, I’m inclined to ask if we should talk about that use case first, so I can suggest a better way to solve that, before we deep dive into the technical question.

Can you tell me a little bit more about what you are trying to do and why?

Thanks!

3

Thanks for your reply!

(I bet I'm just using cobbler wrong and I'm going to look like a doofus.)

Basically, I just like editing yaml files better than plugging stuff
into cobbler. Cobbler (or at least the version that ships with Centos
6) isn't really flexible enough that I'm willing to call it my
canonical inventory. I never know what future variable I'm going to
want in my inventory. Ansible's host_vars files are totally flexible.

My imaginary workflow goes something like this:

1) find out that I need a new virtual server
2) type out a yaml file that describes how that server should be set
up by cobbler (OS, networking, disk partitioning etc..)
3) run ansible to populate cobbler, install kickstart snippets, and
start up the vm with koan.
4) run various ansible plays on that fresh shiny new VM to get it to
do whatever I want it to do.

I could define everything in host_vars files and hit 'go'. If I
started at cobbler I'd have to invoke cobbler system add (which I'd
probably screw up a few times) then I'd have to edit kickstart
snippets. The kickstart snippets are particularly important because
they define how the disk gets partitioned/LVM'ed on the new VM.
Scripting the data entry to cobbler is an obvious way to make it
easier and less error prone and templating the kickstart snippets for
disk partitioning does the same thing. If I'm already thinking of
doing that, why not do it with ansible and throw in the koan bit to
launch the new VM?

As added background, I already wrote a module that uses the cobbler
xmlrpc interface to populate host_vars files. That's dirt simple.
Just read data from xmlrpc, open yaml file, add/update variables, save
yaml.

4

Got it.

Yes I can see defining variable data in Cobbler would be troublesome, in which case I’d definitely want to keep group_vars and host_vars in Ansible YAML files regardless.

In the case of driving Cobbler from YAML, I’d think it might be easier to just write an API script that talked to cobbler to do that, as Cobbler has a lot of structured data in it and driving Cobbler from Ansible would be like cracking a safe through the keyhole of a room.

(I have made the same objection to Cisco driving Cobbler from Puppet, but they didn’t listen to me :))

Now, given the idea of using Ansible to kick off provisioning and wait for completion is pretty interesting, especially where you could wait for a playbook to complete, however, I’d do that quite differently.

What I’d prefer to see is the kickstart post set up the SSH key, and that’s about it.

One of the features we are adding in AWXis the ability to have a simple callback, where a machine can make a http:// request to start a job to configure itself. This will make it very easy for any provisioning system to fire off Ansible when it gets ready to take the configuration of the machine the rest of the way – whether this is cloud or bare metal. (AWX will be available at the end of the month – see http://www.ansibleworks.com/ansibleworks-awx/ )

I could definitely see a lot of cobbler ansible module types to ensure configurations are in one place or the other, but it just seems to be that that sort of functionality – being able to configure the provisioning tool through just text files versus the main interface, should be done in that project instead.

Plus, I think you’d lose out on some core usefulness in Cobbler command line – namely, all the validation and checking it does on user inputs.

5

Thanks again for your reply!

In the case of driving Cobbler from YAML, I'd think it might be easier to
just write an API script that talked to cobbler to do that, as Cobbler has a
lot of structured data in it and driving Cobbler from Ansible would be like
cracking a safe through the keyhole of a room.

Good point. I could put the data in host_vars files, but read it
outside of ansible. I could even do that from inside a module
launched by ansible...wheee And the template module already has that
data, so that could handle the kickstart template.

Now, given the idea of using Ansible to kick off provisioning and wait for
completion is pretty interesting, especially where you could wait for a
playbook to complete, however, I'd do that quite differently.

I probably explained myself badly. I don't think there's much difference.

What I'd prefer to see is the kickstart post set up the SSH key, and that's
about it.

Yeah, that's exactly what I do. Everything beyond that is done by
ansible after the VM is up. Kickstart failing is ugly, so I like to
keep kickstart as minimal as possible.

One of the features we are adding in AWXis the ability to have a simple
callback, where a machine can make a http:// request to start a job to
configure itself. This will make it very easy for any provisioning system
to fire off Ansible when it gets ready to take the configuration of the
machine the rest of the way -- whether this is cloud or bare metal. (AWX
will be available at the end of the month -- see
http://www.ansibleworks.com/ansibleworks-awx/ )

So the new box just does a curl or wget or whatever and then the AWX
server runs ansible plays to do whatever you want? Sounds cool.
Sounds like ansible-pull but with fewer requirements.

I could definitely see a lot of cobbler ansible module types to ensure
configurations are in one place or the other, but it just seems to be that
that sort of functionality -- being able to configure the provisioning tool
through just text files versus the main interface, should be done in that
project instead.

So, a python script that reads yaml and talks xmlrpc with cobbler
should be considered more in a cobbler context than an ansible
context. That makes sense. And if one happens to use it with
ansible, that's fine.

Plus, I think you'd lose out on some core usefulness in Cobbler command line
-- namely, all the validation and checking it does on user inputs.

Are you saying the xmlrpc interface doesn't do the same validation &
checking as the command line? Or are you warning me away from editing
the cobbler back-end files?

Thanks again for taking the time to answer my questions!
-Dylan

6

> One of the features we are adding in AWXis the ability to have a simple
> callback, where a machine can make a http:// request to start a job to
> configure itself. This will make it very easy for any provisioning
system
> to fire off Ansible when it gets ready to take the configuration of the
> machine the rest of the way -- whether this is cloud or bare metal. (AWX
> will be available at the end of the month -- see
> http://www.ansibleworks.com/ansibleworks-awx/ )

So the new box just does a curl or wget or whatever and then the AWX
server runs ansible plays to do whatever you want? Sounds cool.
Sounds like ansible-pull but with fewer requirements.

> I could definitely see a lot of cobbler ansible module types to ensure
> configurations are in one place or the other, but it just seems to be
that
> that sort of functionality -- being able to configure the provisioning
tool
> through just text files versus the main interface, should be done in that
> project instead.

So, a python script that reads yaml and talks xmlrpc with cobbler
should be considered more in a cobbler context than an ansible
context. That makes sense. And if one happens to use it with
ansible, that's fine.

Exactly, it's something like wget
http://ansible.example.com/callbacks/token=XXXXXX

where XXXX is some token you're going to have to know that corresponds with
being able to run the playbook this way.

Ansible will behind the scenes pass in "--limit <requesting_hostname>" and
run the playbook on that new system.

> Plus, I think you'd lose out on some core usefulness in Cobbler command
line
> -- namely, all the validation and checking it does on user inputs.

Are you saying the xmlrpc interface doesn't do the same validation &
checking as the command line? Or are you warning me away from editing
the cobbler back-end files?

Sorry it has been a while and I forgot about that, the XMLRPC interface
does do checking.

Definitely don't edit the backend files.

Thanks again for taking the time to answer my questions!

No problem! Glad to help!

7

I just finished a very early version of a script that populates cobbler from yaml. Is this list a good place to post such a thing, or is that bad form? It’s not ansible specific, but it’s something I developed to use with ansible and I think other ansible users might find it useful.

8

Cobber list would be the place, I think, if you are populating cobbler from YAML?

Though if ansible is involved in talking to cobbler or there’s a module, sure.