[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[virt-tools-list] Re: libosinfo - another try



On 23/10/09 11:08, Daniel P. Berrange wrote:
On Fri, Oct 23, 2009 at 10:44:38AM +0100, Matthew Booth wrote:

Yes. OVF mandates usage of an OS taxonomy defined in CIM. You can find
the canonical list by downloading the spec in XML form from here:

http://www.dmtf.org/standards/cim/cim_schema_v2220/cim_schema_2.22.0Final-XMLAll.zip

Search in there[1] for 'BSDUNIX', which is in the middle of the list.
Note that there are some significant omissions from this list (including
Fedora, for eg). Also note that it's very inconsistent:

* Windows (R) Me
* Windows XP
* Windows Vista
* Windows 2000
* Microsoft Windows Server 2008

vs

* RedHat(sic) Enterprise Linux

Do note that these descriptions are just that. They actually correspond
to a numerical ID which is further up. Maybe this means we can get them
fixed.

Welcome to the failboat :-(  That list is utterly useless. It distinguishes
different Windows versions, but not different Linux versions. Integer ID
values are just horrible.

The version disparity was my point ;) Also agree integer ID values are horrible.


IMHO for osinfo we should stick the full official release names given by
the vendor/distributor, and as I suggested in other thread go for a RDF
URI scheme for unique identifiers since that's the only way you get
something that's easily extendable by independant 3rd parties - we can't
rely on a central person maintaining lists of integer IDs.

One of the extra pieces of metdata we have can then be a category mapping
to the nearest practical CIM OS name / ID

In fairness to the CIM guys, they're trying to curate a particularly messy universe. That they've done a better job of categorising Windows than they have of Linux distros is almost certainly down to their input to date. It may suck, but it does have more traction than anything else and it should at least suck consistently and predictably. Lets engage with them to improve the data, and ensure that we have a good, consistent story for mapping to it. Ignoring them will not help improve interoperability, and will risk marginalising our implementation.

I will be sending them a request to add some new entries in due course,
but I don't see how this list can ever be anything other than horrible.

Yep, we can't rely on a centrally maintained database since that prevents
the goal of allowing users to easily add their own variants.

That said, it is canonically horrible, so we should map to it. May I
suggest that the numerical CIM TargetOSType identifier is mandatory?
We'll have to think of something both consistent and useful to do with
entries not currently in the CIM list, though.

IMHO CIM data should just be an optional extra metdata tag. So if we have
a mapping to the CIM OS then include it, but otherwise ignore it because
it is just horrible

I considered this, but as soon as a tag becomes optional it becomes almost irrelevant. I'd prefer a scheme where it was mandatory, and had some scheme which allowed it to be updated as the CIM data improves.

Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]