RFC: libosinfo: Library for virt OS/distro metadata 3

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

 



Hi all,

I've done the initial work for a new library, libosinfo (better name
recommendations appreciated). This library will provide OS meta data for use
in virt applications, replacing the dictionary we currently keep in virtinst.

This is based off of a post by Dan Berrange:

https://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00028.html

The code can be fetched with:

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

Check out the TODO list for a simple roadmap.

http://fedorapeople.org/~crobinso/osinfo/TODO


The public API looks like:

/**
 * Values stored in the OS dictionary
 */
enum _os_value_type {
    OS_VALUE_NAME = 1,          /** Human readable family/distro... name */
    OS_VALUE_MEDIA_INSTALL_URL, /** URL to an install tree */
};
typedef enum _os_value_type os_value_t;

int     os_init();
void    os_close();

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);

int     os_lookup_value         (os_value_t value_type,
                                 const char *os_id,
                                 char **value);

The unique identifier for each distro is its 'id', which is a simple human
readable string, similar to values we use for virt-install --os-variant today.

The user will ask the API for available families/distros/releases/updates,
which will return a list of ids. We then pass an id to os_lookup_value to
actually retrieve data. The family/distro/... separation will likely be
removed pretty soon, in favor of an arbitrary hierarchy, where every OS
can have child OSes: no doubt hardcoding the family/distro/... split would
come back to bite us in the ass.

As an example, the following code will list the 'Name' of every id at
the'family' level, where name is full name of the OS (id = rhel5.3, name = Red
Hat Enterprise Linux 5.3):

    char *value = NULL;
    char **namelist = NULL;
    int i, num_fams;

    if (os_init() < 0)
        goto error;

    if ((num_fams = os_list_families(&namelist)) < 0)
        goto error;

    for (i = 0; i < num_fams; ++i) {
        if (os_lookup_value(OS_VALUE_NAME,
                            namelist[i],
                            &value) < 0)
            goto error;

        printf("%s\n", value);
        free(value);
    }

error:
   free(namelist);
   free(value);
   os_close();

There is a simple tool called 'osinfo-tool' which allows listing an ASCII repr
of the OS hierarchy, and listing all values for an individual id (which is
pretty sparse at the moment since most of these values haven't been filled
in yet).


So, things that I'm interested in feedback on:

- How do we expect apps to list OS choices? Currently, virt-manager lists
  type (linux, windows, unix, etc.) and associated distros (Fedora 8, RHEL4,
  Debian Lenny, etc.). The linux/windows/unix info isn't represented in the
  xml (should it be?) so the best way seems to be:

  Distro
    |
    --> Release
          |
          --> Update

  Ex.

  RHEL
    |
    -> RHEL5
        |
        -> 5.0
           5.1
           5.2

  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.

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

- Querying for device values (supported buses, models, etc.). Dan's original
  proposal talks about this; to recommend a default with the best chance of
  actually working, we need to know:

  - OS being installed
  - Virt type ('hvm' vs. 'xen')
  - Guest Architecture (i386, x86_64, ...)
  - Hypervisor (kvm, qemu, xen, vbox, ...)
  - Hypervisor version
  - Libvirt version

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

  It works, but its pretty tedious, and I'm afraid that we would need
  even more info to make a correct choice in the future, and the above
  isn't flexible. We may also need some of the above info for other values
  (ACPI/APIC settings, returning a proper install url may depend on arch).
  Any suggestions?

- os_init and os_close: Any better ideas for this? os_init just parses the
  xml document, os_close frees it. We could run os_init with the first API
  call, but I think that makes it less clear that the user would then
  need to call os_close().

Any feedback appreciated.

Thanks,
Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux