WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

[Xen-API] RE: handling "guest tools" versions

To: Andrew Peace <Andrew.Peace@xxxxxxxxxxxxx>, xen-api <xen-api@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-API] RE: handling "guest tools" versions
From: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Date: Tue, 25 May 2010 10:42:18 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Tue, 25 May 2010 02:42:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <7B14C05615DB43488B85E143995BD5498BF032089E@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <81A73678E76EA642801C8F2E4823AD21807FFE68ED@xxxxxxxxxxxxxxxxxxxxxxxxx> <7B14C05615DB43488B85E143995BD5498BF032089E@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acr7RFE6sHPWnds1QTW6uX4DvYsPPAAFk6CwACSkBtA=
Thread-topic: 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

<Prev in Thread] Current Thread [Next in Thread>