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

[Daniel P. Berrange]

On Fri, Oct 23, 2009 at 01:42:58PM +0100, Matthew Booth wrote:
> On 23/10/09 11:08, Daniel P. Berrange wrote:
> >On Fri, Oct 23, 2009 at 10:44:38AM +0100, Matthew Booth wrote:
> >
> >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'm not saying we should ignore them, we should maintain the mapping
to their document names whereever possible. The CIM list cannot be
our master list though because it is woefully incomplete & given the
rate at which new OS arrive, it will always be incomplete. In addition
they have already standardized on names that are just plain wrong.

> >>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.

It is unavoidable that it be optional since the CIM data is inevitably
outdated. By standardizing on a scheme that follows the OS vendors own
official naming we avoid a need to rely on a central authority to 
declare what the names are which is key if this is to be maintainable
and extendable.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|