| |
|
 |
|
 |
|
|
|
| |
|
|
xen-api
[Xen-API] RE: handling "guest tools" versions
Hi,
Andrew Peace wrote:
> I think it would be great to have a solution to this problem - it
> definitely can be annoying. The solution you suggest seems reasonable;
> in this case, would the presence of the immutable flag be sufficient to
> suppress the warning, or would all the keys (including immutable) have
> to be present?
Hm, I think it might be better if an appliance author can leave out all the
version numbers rather than forcing them to put in dummy values. In that case
the word "immutable" isn't quite right... perhaps
/local/domain/<domid>/attr/PVAddons/UpgradeNotPossible
?
> The guest tools could be perhaps trivially extended so
> that they can be started in a way that causes the flag to be written
> (e.g. on Linux by checking a config file) so that appliance authors
> don't have to invent their own init scripts.
That's a good idea!
> As a future addition it may also be worth thinking through how an
> appliance can indicate that it is out-of-date so that a user may be
> prompted to update the entire appliance (a GUI might display a warning
> that, when clicked on, follows a URL, for example).
I agree. I think this links with Anil's point:
Anil Madhavapeddy wrote:
>> If the
>> user (as I do) modifies the Linux PV tools to do custom stuff, then
>> there's no way to separate that from the base PV drivers version. It
>> doesn't matter much for Linux, but it does a lot more for Windows where
>> the PV drivers actually do something.
It sounds like we need some more generic mechanism for reporting multiple
in-guest software versions so that a clever management tool can trigger (or
just suggest the need for) upgrades.
I'll go and write up the modified proposal on the xen wiki.
Cheers,
Dave
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
|
|
| |
|
Home