I also think that this script can only used on a spacewalk server.
I would prefer to use the native rhn api instead.
Vincent
We merged it in last week, so there’s hardly anyone to break.
I think it’s fine if it requires configuration, in fact, it seems it should require an INI for the spacewalk server anyway 
Yes, definitely.
It should at least degrade nicely if there is some new hotness that is not yet in a released Satellite server.
I'll rewrite it (remove some of the items I never finished) and do a new pull-request.
What about having an option to regenerate the whole cache (all host info) in the standard options of inventories ? The aim is to have a single option to invalidate and renew the cache from a cronjob.
PS Could we not use the ansible.cfg for inventory options as a default ?
Cache invalidation can more or less be a convention, yes. We should stick with the parameter that the ec2 module adds now, and add more if need be.
There’s nothing in ansible that needs to know about those flags to make it a requirement, but obviously calling it with shell is ok.
I don’t think ansible.cfg is necc. ideal in the sense that you might want to use multiple inventory sources (like two different ec2 INI’s) at different times (say stage vs prod? or different customers in a MSP or hosted arrangement?), so in that case, you might have two different INI files.
–Michael
A solution could be that the inventory-script's name should match the section name in the config, e.g. spacewalk.py will look for section [inventory:spacewalk] and rhn.py will look for section [inventory:rhn].
Just an idea to avoid having to modify inventory scripts (even if only to change the config-file to use).
Yeah, I don’t really care for that, I don’t think.
Renaming the script would be somewhat awkward and then the script would have to look at argv[0] to decide the section name, which would be confusing to have to explain to everyone I think.
Maybe I’m wrong though, but I’d like things, because they do not already do this, to remain consistent.
Someone was nice enough to send a contributing to the project, so pull
requests should be send to ansible's main project.There is no reason to have a seperate repo for this when we already have
lots of great inventory modules in core.The difference is that the original inventory script does not require any
configuration (as it uses spacewalk-report) whereas if I would add my stuff
to it, it requires configuration directives to work.
You mean adding rhn? How are you going to make the distinction between
spacewalk-report and using the rhn-api?
Vincent
Well, I really meant Satellite. But if it works with RHN too, great.
One should be able to talk to the API endpoint and figure out what you are talking to.
I’d hope.
That all being said, if it just uses the RHN API, isn’t that fine? I think it would be.
Well, I really meant Satellite. But if it works with RHN too, great.
One should be able to talk to the API endpoint and figure out what you are
talking to.
I'd hope.That all being said, if it just uses the RHN API, isn't that fine? I think
it would be.
As far as I understand, the current inventory script uses a wrapper script
to get info from a satellite server, but can only be run on a satellite server
(correct me if i'm wrong).
The inventory script is not talking to the api itself...
Vincent
Yes, I’m suggesting to merge dag’s ideas and this one, or maybe we should just replace it with Dag’s, if that gets us RHN and deployed Satellite support.
Ok.
I’m going to test Dag’s script
Just tested Dag's script but ran into some problems
- I think it's not compatible with the latest RHN api. ( listSystems
-> listUserSystems )
- sysid must be integer and not a string ( int(system['id'] )
- all returned groups contain the same (all) hosts. haven't looked into this.
Vincent
Since the RHN API is XMLRPC you should be able to do listMethods on the top level to see what functions it supports.
Unless it’s not Python XMLRPC. That’s a non-standard method.
Though this does tend to imply it should be importing into a database instead, so it’s easier to lookup later, or at least caching very very smartly
Vincent,
It works in our infrastructure using RHN Satellite 5.5.0 (the latest IMO).
Just tested Dag's script but ran into some problems
- I think it's not compatible with the latest RHN api. ( listSystems
-> listUserSystems )
- sysid must be integer and not a string ( int(system['id'] )
- all returned groups contain the same (all) hosts. haven't looked into
this.Vincent,
It works in our infrastructure using RHN Satellite 5.5.0 (the latest IMO).
Dag,
I'm connecting to RHN (rhn.redhat.com) and yields the same errors I
had with my own
scripts connecting to it.
Weird....
Anyway, see you at the meetup. Maybe I can show you
Is there a script available that will connect to our Spacewalk server from our Ansible server (using an api) to get the host/group information?
Thanks,
Tracy
Yes, in the source tar (or from github) there is plugins/inventory/spacewalk.py.
Hi James,
Unless I am missing something spacewalk.py needs to be executed on the spacewalk server, not the ansible server, correct?
Thanks,
Tracy
It does use the spacewalk-reports package. I honestly don’t know if you can configure it to point at a remote server.
It presumes you are running Ansible from the spacewalk server if you can’t - but there’s also a REST API for Satellite/Spacewalk, so I imagine alternatives could also be built fairly easily.
The documentation on the Spacewalk/Satellite API was sufficient for me to get a authentication plugin for Cobbler going with a live server, and I’m sure Red Hat might also be able to help with questions.