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();
voidos_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
___
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] RFC: libosinfo: Library for virt OS/distro metadata 3
On Mon, Jun 15, 2009 at 07:16:56AM -0400, John Levon wrote: 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. I think this is the way to go. Flat list + properties, and allow apps to build hiearchies on the fly as needed, based off properties. 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. A single XML file would be pretty horrible for package upgrades. With a flat list we can have 1 XML file per distro. If we allow multiple search paths for XML files, we can have the stadnard shipped ones in /usr/share/osinfo, and customized ones in /etc/osinfo the latter overriding (or inheriting from) the former. - 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. Download/install URLs already require that we do separate IDs :-) 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 :| ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] RFC: libosinfo: Library for virt OS/distro metadata 3
On Mon, Jun 15, 2009 at 11:28:09AM -0400, Cole Robinson wrote: 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. I can see doing something like os_info_set_install_prop(os_info_t info, int prop, char *propval) So the API user might do: os_info_set_install_prop(myinfo, OS_INSTALL_VIRT_TYPE, hvm); os_info_set_install_prop(myinfo, OS_INSTALL_ARCH, x86_64); os_info_set_install_prop(myinfo, OS_INSTALL_HV_TYPE, kvm); This isn't going to work as we most definitely have more than one value of all of these settings. Instead we need to pass in a list of environments. Each one would specify a particular combination of the values above (along with a 'preferred' setting methinks). regards john ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] RFC: libosinfo: Library for virt OS/distro metadata 3
On Mon, Jun 15, 2009 at 12:11:18PM -0400, Cole Robinson wrote:
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.
I can see doing something like
os_info_set_install_prop(os_info_t info, int prop, char *propval)
So the API user might do:
os_info_set_install_prop(myinfo, OS_INSTALL_VIRT_TYPE, hvm);
os_info_set_install_prop(myinfo, OS_INSTALL_ARCH, x86_64);
os_info_set_install_prop(myinfo, OS_INSTALL_HV_TYPE, kvm);
This isn't going to work as we most definitely have more than one value
of all of these settings.
The values the user sets are for what kind of guest they are installing
at that moment (x86_64 kvm in this case, i686 xen PV in another).
That's backwards, though. I don't care about kvm or xen. I care about
installing a particular guest type, and want the library to tell me the
best method. To do that it needs to match guest needs against host
capabilities, and that implies the above properties need to be
multi-valued. There is no one golden setup even on a single system and
it would be a major mistake to presume there ever will be.
Instead we need to pass in a list of environments. Each one would
specify a particular combination of the values above (along with a
'preferred' setting methinks).
Maybe we can avoid an explicit 'preferred' concept, and just return a
list of supported values to the user. osinfo will put it's 'preferred'
choice as the first in the list, but if the user wants to differ, they
can choose from the other values in the list.
There may be more than one preferred setting ('kvm or xenpv, but I'd
avoid xenhvm'). Possibly we need a more nuanced notion.
regards
john
___
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] RFC: libosinfo: Library for virt OS/distro metadata 3
John Levon wrote:
On Mon, Jun 15, 2009 at 12:11:18PM -0400, Cole Robinson wrote:
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.
I can see doing something like
os_info_set_install_prop(os_info_t info, int prop, char *propval)
So the API user might do:
os_info_set_install_prop(myinfo, OS_INSTALL_VIRT_TYPE, hvm);
os_info_set_install_prop(myinfo, OS_INSTALL_ARCH, x86_64);
os_info_set_install_prop(myinfo, OS_INSTALL_HV_TYPE, kvm);
This isn't going to work as we most definitely have more than one value
of all of these settings.
The values the user sets are for what kind of guest they are installing
at that moment (x86_64 kvm in this case, i686 xen PV in another).
That's backwards, though. I don't care about kvm or xen. I care about
installing a particular guest type, and want the library to tell me the
best method. To do that it needs to match guest needs against host
capabilities, and that implies the above properties need to be
multi-valued. There is no one golden setup even on a single system and
it would be a major mistake to presume there ever will be.
No presumption here. In virt-manager, those above values are chosen by
the user (qemu vs. kvm vs. xenner, arch, xenpv vs. xenfv). I'm not
saying those above API calls would be hard coded, it would be the result of:
./virt-install --connect qemu:///system --arch x86_64 --virt-type kvm
--os-variant foobar ...
I hear you that it would be nice if the user could say 'here's the OS I
want, here's my host config, DO IT!', and to some degree
virt-manager/virt-install already plays that role, but at the osinfo
library it can come later and isn't a big priority at the moment. I'm
interested in just reaching parity with the current virtinst osdict
solution for now.
Instead we need to pass in a list of environments. Each one would
specify a particular combination of the values above (along with a
'preferred' setting methinks).
Maybe we can avoid an explicit 'preferred' concept, and just return a
list of supported values to the user. osinfo will put it's 'preferred'
choice as the first in the list, but if the user wants to differ, they
can choose from the other values in the list.
There may be more than one preferred setting ('kvm or xenpv, but I'd
avoid xenhvm'). Possibly we need a more nuanced notion.
regards
john
Thanks,
Cole
___
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] RFC: libosinfo: Library for virt OS/distro metadata 3
On Mon, Jun 15, 2009 at 12:51:49PM -0400, Cole Robinson wrote: The values the user sets are for what kind of guest they are installing at that moment (x86_64 kvm in this case, i686 xen PV in another). That's backwards, though. I don't care about kvm or xen. I care about installing a particular guest type, and want the library to tell me the best method. To do that it needs to match guest needs against host capabilities, and that implies the above properties need to be multi-valued. There is no one golden setup even on a single system and it would be a major mistake to presume there ever will be. No presumption here. In virt-manager, those above values are chosen by the user (qemu vs. kvm vs. xenner, arch, xenpv vs. xenfv). We aren't writing libvirtmanager though. I'm not saying those above API calls would be hard coded, it would be the result of: ./virt-install --connect qemu:///system --arch x86_64 --virt-type kvm --os-variant foobar ... I hear you that it would be nice if the user could say 'here's the OS I want, here's my host config, DO IT!', and to some degree virt-manager/virt-install already plays that role, but at the osinfo library it can come later ^ No, you're proposing an API which prevents it, that is, one value per key (one hypervisor type, one arch, etc.). That's precisely my complaint. By all means make the current /implementation/ throw its hands up if given more than one virtenv[1]. Just don't encode it into the API. regards john [1] guest-arch+hypervisor-type+virt-type+... combo ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
