[virt-tools-list] (no subject)

[otheus uibk]

>
> > Perhaps I phrased it the wrong way.
> >
> > *Excluding the multi-fact exceptions* is it ever a problem to output the
> > fact and immediately exit?
>
> I think you're missing the point that there might not be "a"
> hypervisor.  It's entirely possible for the hypervisor to offer two
> distinct sets of services, or even to look like two different
> platforms (Azure + Xen).  I'm wondering why this is important.
>
>
Why it's important? Because (1) it's inefficient, and I care about
efficiency, and (2) because it leads to possibly incorrect results with
unpredictable consequences.

I came to this project because our datacenter runs RedHat Virtualization
and we use Puppet to configure hosts; Puppet uses facter. The facter fact
which runs virt-what stopped working properly in RHEL7. Why? Because the
RHEL7-based puppet package added virt-what as a dependency. But obviously
"rhev" is not yet supported. This broke the fact. But because virt-what
exits with error when run as non-root, the fact broke conditionally.

Now consider this: facter runs virt-what and discards all but the last line
of output. So in such a system as you describe above, facter would provide
either wrong, incomplete, or varying facts.

Also, back to my point (1) above, facter runs on our systems every 30
minutes. At least. (That's another battle of mine; to get that default
changed). At any rate, I had in mind to make several optimizations.

I am fully prepared to accept the argument that facter's use/reliance on
this tool is incorrect.

I suppose virt-what is key in implementing your virt-top and other
virt-tools?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20160324/11349d84/attachment.htm>