From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: Proposal: deprecate "vncviewer" option in xl domain config file Date: Tue, 22 Apr 2014 17:07:35 +0100 Message-ID: <20140422160735.GQ7712@zion.uk.xensource.com> References: <20140422151912.GM7712@zion.uk.xensource.com> <1398181856.4880.73.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1398181856.4880.73.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Ian Jackson , Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, Apr 22, 2014 at 04:50:56PM +0100, Ian Campbell wrote: > On Tue, 2014-04-22 at 16:19 +0100, Wei Liu wrote: > > Hi all > > > > When I'm working on (de-)serialization of domain configurations I found > > "vncviewer". I now propose to deprecate it. > > > > What it does is that if you have it set in your domain's config file and > > do "xl create cfg", xl will automatically spawn a vncviewer for you. > > This option actually controls the creation process of a domain but has > > nothing to do with domain configuration at all. > > > > This option is buggy because it's also saved as part of domain state > > when you do save / restore. > > Where is it saved? > The domain config file is saved, then used when restoring. Restoring process involves re-parsing that config file. > > Consider user migrates a domain to a remote > > host, xl will try to auto-spawn vncviewer on the new host. This behavior > > doesn't make sense at all. > > > > Further more it becomes an obstacle for the work to (de-)serialization > > domain configurations. If we want to preserve this option we then need > > to create abstraction for a config file in xl or libxl. This either > > introduces lots of work without much benefit (if we add out-of-band > > infomation in xl) or pollute libxl public interface. > > > > I propose to deprecate this option. > > > > What I will do is: > > 1. config file still supports this option but it will prints out a > > warning about its deprecation. > > 2. this option is not saved as domain state when doing save / restore, > > so when you restore a domain xl will not auto-spawn vncviewer. > > > > This may create a minor regression, but it's in no way critical. In > > any case the right way to auto-spawn vncviewer is to use "-V" in "xl > > create". And existing user of this config file option can also use "-V" > > to work around this regression. > > > > Comments? > > Rather than throwing the baby out with the bathwater can't we just say > that this option is only obeyed for the initial domain creation and not > for any subsequent migration or restore? What would avoid the need to > propagate it along with the save/migrate image. > I think this is just wording issue. My "xl-json" format patch does this already. I'm OK with any approach as long as I don't need to propogate it. :-P Wei. > Ian. >