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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
