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

[Matthew Booth]

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