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

[fedora-virt] Re: [et-mgmt-tools] RFC: libosinfo: Library for virt OS/distro metadata 3



On Sun, Jun 14, 2009 at 06:50:02PM -0400, Cole Robinson wrote:

> git clone http://fedorapeople.org/~crobinso/osinfo/.git

I'm not convinced by the "arbitrary hierarchy" thing: I just don't see
how that could possibly be useful. Surely it's either an entirely flat
namespace, or a shallow structured one like you have.

The flat namespace would be a set of keys and multiple values for each
key. One value would be "os type" (linux, windows, etc.). You'd most
likely have a "generic" entry still for fallback.

An alternative is to represent the hierarchy in the UNIX way, via the
filesystem:

/var/lib/osinfo/
/var/lib/osinfo/linux/info.xml
/var/lib/osinfo/linux/fedora/info.xml
/var/lib/osinfo/linux/fedora/8/info.xml

The fallback is pretty obvious then. Maybe it's over the top. The idea
of a single delivered XML file that users edit does trouble me though.
Maybe we at least have two files, one for customisations.

> int     os_init();
> void    os_close();

Always, always, always, pass back an opaque identifier in an API - you
never know when you'll need to track per-thread state. It's generally a
good idea to pass in a version define too.

The XML parsing itself should happen lazily. We might want to let the
user specify a file, for example.

> int     os_find_families        (char ***list);
> int     os_find_distros         (const char *parent_id, char ***list);
> int     os_find_releases        (const char *parent_id, char ***list);
> int     os_find_updates         (const char *parent_id, char ***list);

Regardless of the hierarchy question I hate the idea of exposing it in
the API like this.

There's really two (hopefully three eventually) things this library
needs to do: provide a list of everything it knows about so the user can
select it in a GUI or whatever, and provide configuration
recommendations given a particular set of values.

I don't think the library can make any assumptions about how the former
might look. It just needs to return some thing like:

	struct osinfo {
		const char *id;
		nvpair_list_t values;
	};

Either allocated as an array (probably easiest) or in a list. It's then
up to the client to decide what hierarchy to actually use, and it's all
dependent on what values they pick out of the nv list.

(The third thing is to identify OS types based upon installation media
when possible.)

>   If we do away with the family/distro/... distinction, the user won't have
>   much choice in the matter, but the 'family' concept (e.g. value of
>   'Red Hat') isn't very useful to expose to a user.

If you mean API user, think "icon".

> - How should we handle derivatives like Scientific Linux + CentOS: should we
>   expect users to understand they are based on RHEL, or give them explicit
>   IDs?

Explicit IDs. You'd be surprised.

>   We would need to find the intersection of what the OS, the hypervisor,
>   and libvirt support, and return what we decide is the best choice.
> 
>   How to expose this in the API? We could simply have one long function
> 
>   os_lookup_device_value(char *os_id, char *virt_type, char *arch, ...)

The API user should pass in an nvlist, where a set of the names are
defined and known about. The response needs to indicate whether it's a
preferred setting ("would like virtio") or a required one.

regards
john


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