Feature #4468

Virtual fact should return a list for hosts that can support multiple virtual types

Added by Mark Lehrer almost 3 years ago. Updated over 1 year ago.

Status:AcceptedStart date:08/04/2010
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:library
Target version:-
Keywords: Affected Facter version:
Branch:

Description

The kernel I use on many systems is one that can do xen0, openvzhn, and also virtualbox. Unfortunately, the facter just shows xen0.

Related issues

Related to Facter - Feature #4561: Structured data should be supported Accepted 05/18/2012 05/18/2012

History

#1 Updated by Paul Nasrat almost 3 years ago

  • Status changed from Unreviewed to Needs Decision
  • Target version set to 1.6.0

need to think about this but post 1.5.8

#2 Updated by Daniel Pittman almost 3 years ago

FWIW, we have recently hit this same problem at a different level:

We use both KVM virtual hardware machines and OpenVZ container system to divide up machine. Specifically: have have KVM guest systems that are OpenVZ host systems.

To avoid things like installing hardware layer management tools on the OpenVZ host system we are going to have to do something that reports both “KVM guest” and “OpenVZ host” at the same time.

We have no current design to solve this, although I hope to have something in the next week or so to address it.

#3 Updated by James Turnbull about 2 years ago

  • Assignee set to Nigel Kersten

#4 Updated by Nigel Kersten about 2 years ago

Does it make any sense to return this as a comma-separated list in a string ?

That’s our only real option until Facter supports rich data types.

#5 Updated by Daniel Pittman about 2 years ago

On Thu, Apr 21, 2011 at 10:24, Mark Lehrer mark@knm.org wrote:

Does it make any sense to return this as a comma-separated list in a string ?

This would work fine for me.  I was thinking about something like the processorcount arrangement, but that might be over-engineering it.

So, er, changing the incorrect “there can be only one” fact will actually break production code, since we defined it that way and the values of facts are totally API.

However, the processor count like model of “export one boolean for each matching virtual type” would not have that problem. :)

Daniel

#6 Updated by Michael Stahnke almost 2 years ago

  • Target version changed from 1.6.0 to 144

#7 Updated by James Turnbull almost 2 years ago

  • Category set to library

#8 Updated by Nigel Kersten almost 2 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)
is_virtual => true
virtual => vmware

Just for some context.

The semantic intent of “virtual” can actually have multiple values for some environments as others have pointed out, but I’m reluctant to provide a comma-separated string here before Facter can provide arrays for facts.

I propose in the meantime we continue to use “is_virtual” as a boolean, leave the current behavior of “virtual” alone, and instead provide “virtual_$provider” boolean facts.

#9 Updated by Ken Barber over 1 year ago

  • Tracker changed from Bug to Feature
  • Target version changed from 144 to 186

#10 Updated by Adrien Thebo over 1 year ago

  • Target version changed from 186 to 14

This would work best with a 2.0 release where we support structured data, and thus can store all possible values in an array.

#11 Updated by Ken Barber over 1 year ago

  • Target version changed from 14 to 186

#12 Updated by Daniel Pittman over 1 year ago

  • Target version deleted (186)

Also available in: Atom PDF