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. > > 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. > The single XML file approach certainly isn't the way forward. There are numerous ways we can solve the 'let admin customize osinfo' problem, but that can come after pinning down the API I think. >> 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. Sounds good, but I'm not sure what you mean by passing in a version define? > > 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. > Agreed, I think Dan's mail covered this pretty well. > (The third thing is to identify OS types based upon installation media > when possible.) > Agreed, I'd like to do all detection here in the future. >> 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. > 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"); Then lookup device properties like you would any other prop. Thanks! - Cole _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
