virt_facts: Module to gather facts of a guest on a KVM host

[dagwieers]

This is a module much like vsphere_facts and hpilo_facts, returning similar information useful for provisioning (like hardware info, uuid and mac-address(es)).

[dagwieers]

Currently the module expects to get run on the target host using Ansible (unlike vsphere_facts and hpilo_facts), in a later phase I would like to remotely address the host directly from the command-and-control system using local_action.

[mpdehaan]

Ok so I am thinking I am being too overzealous about merging stuff into core.

I would recommend we put these in contrib and let you host them. I want to keep virt in there but KVM or HP hardware specifics are a bit too niche to be in core, and it increases the volume of stuff we have to maintain.

Don't get me wrong, this stuff is TOTALLY AWESOME.... and we need to do a better job of linking to all the core stuff in much more prominent ways (like a page that is part of the doc site).

[dagwieers]

In my opinion they all belong together as most environments are not homogenous. We will probably also have rhev_facts and rhev_boot, and for my own pleasure I intend to do a vbox_facts and vbox_boot too.

Obviously, if they are not in core they will not get the same attention, but it's your call.

[mpdehaan]

Basically my thinking here is things could easily get very site or version specific and people could get frustrated trying to get them to work, in the case of virt booting, just KVM rules out Xen, when the virt module is virt type agnostic, etc. It's basically a consistency thing. However, we do want to point LOUDLY at these, because they are awesome, but I am not sure they should be part of the core release.

In fact, having a strong non-core module list is a HUUUUUUUGE ginormous bonus, because we can say "look at all these awesome modules you can get".

As for RHEV and everything -- yes -- but at this point, my architectural brain says "shouldn't there be an abstraction layer?" Sure the module would grow to be ginormous, but then the interface is more or less the same.

[mpdehaan]

Since all of these are yours, what about a "dag's provisioning modules for ansible" repo? They could all stay together in that way and I am sure it would get a lot of interest.

Basically I am feeling that I need to keep core tight because the volume is sort of overwhelming and should I need to make consistent changes to them, the width is getting too broad, and there are things requiring platforms that many of us don't have, so they are hard to test.

I think creating an ansible-provisioning-modules repo would be awesome.

[dagwieers]

The abstraction layer is in fact having multi-source inventory which can merge facts from different sources.