Feature #4468
Virtual fact should return a list for hosts that can support multiple virtual types
| Status: | Accepted | Start date: | 08/04/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | library | |||
| Target version: | - | |||
| Keywords: | Affected Facter version: | |||
| Branch: | ||||
| Votes: | 0 |
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
History
Updated by Paul Nasrat almost 2 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
Updated by Daniel Pittman over 1 year 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.
Updated by James Turnbull about 1 year ago
- Assignee set to Nigel Kersten
Updated by Nigel Kersten about 1 year 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.
Updated by Daniel Pittman about 1 year 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
Updated by Michael Stahnke 11 months ago
- Target version changed from 1.6.0 to 1.6.x
Updated by James Turnbull 9 months ago
- Category set to library
Updated by Nigel Kersten 9 months 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.
Updated by Ken Barber 6 months ago
- Tracker changed from Bug to Feature
- Target version changed from 1.6.x to 186
Updated by Adrien Thebo 5 months 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.
Updated by Ken Barber 3 months ago
- Target version changed from 14 to 186
Updated by Daniel Pittman 2 months ago
- Target version deleted (
186)