John Levon wrote:
> 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.
>
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
teaches osinfo about our current setup, so it can give us valid
recommendations for device properties and whatnot. This could take place
after we already chose an OS ID.
> 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.
I guess this also raises the question of how we indicate 'return a
single value' vs. 'return a list' when fetching info.
Thanks,
Cole
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
