[libvirt] [Qemu-ppc] [Qemu-devel] [PATCH 1/2] numa: deprecate 'mem' parameter of '-numa node' option

[Igor Mammedov]

On Mon, 4 Mar 2019 15:02:18 +0000
Daniel P. Berrangé <berrange at redhat.com> wrote:

> On Mon, Mar 04, 2019 at 03:54:57PM +0100, Igor Mammedov wrote:
> > On Mon, 4 Mar 2019 13:59:09 +0000
> > Daniel P. Berrangé <berrange at redhat.com> wrote:
> >   
> > > On Mon, Mar 04, 2019 at 02:55:10PM +0100, Igor Mammedov wrote:  
> > > > On Mon, 4 Mar 2019 09:11:19 +0100
> > > > Thomas Huth <thuth at redhat.com> wrote:
> > > >     
> > > > > On 01/03/2019 18.48, Daniel P. Berrangé wrote:
> > > > > [...]    
> > > > > > So I think this patch has to be dropped & replaced with one that
> > > > > > simply documents that memdev syntax is preferred.      
> > > > > 
> > > > > That's definitely not enough. I've had a couple of cases already where
> > > > > we documented that certain options should not be used anymore, and
> > > > > people simply ignored it (aka. if it ain't broken, don't do any change).
> > > > > Then they just started to complain when I really tried to remove the
> > > > > option after the deprecation period.    
> > > >     
> > > > > So Igor, if you can not officially deprecate these things here yet, you
> > > > > should at least make sure that they can not be used with new machine
> > > > > types anymore. Then, after a couple of years, when we feel sure that
> > > > > there are only some few or no people left who still use it with the old
> > > > > machine types, we can start to discuss the deprecation process again, I
> > > > > think.    
> > > > Is it acceptable to silently disable CLI options (even if they are broken
> > > > like in this case) for new machine types?
> > > > I was under impression that it should go through deprecation first.    
> > > 
> > > Yes, it must go through deprecation. I was saying we can't disable
> > > the CLI options at all, until there is a way for libvirt to correctly
> > > use the new options.  
> > 
> > I'm not adding new options (nor plan to for numa case (yet)),
> > -numa node,memdev is around several years by now and should be used
> > as default for creating new configs.
> > 
> > In light of keeping 'mem' option around for old machines,
> > Deprecation should have served for notifying users that legacy
> > options will be disabled later on (for new machines at least
> > if no way found for migration compatible transition for older ones).
> > 
> > What I'm mainly aiming here is to prevent using broken legacy options
> > for new VMs (like in RHBZ1624223 case) and deprecation is the only way
> > we have now to notify users about CLI breaking changes.  
> 
> The idea of doing advance warnings via deprecations is that applications
> have time to adapt to the new mechanism several releases before the old
> mechanism is removed/disabled.  Since the new mechanism isn't fully
> usable yet, applications can't adapt to use it. So we can't start the
> deprecation process yet, as it would be telling apps to do a switch
> that isn't possible for many to actually do.

At least a hope attempt to deprecate 'mem', served its purpose somewhat.
Now it's clear that libvirt defaults to wrong legacy mode and should use
'memdev' instead. I hope that it will be addressed on libvirt side
regardless of the fate of 'mem' deprecation process.
Basically new VM should default to 'memdev' if it's available. 


> In the meantime, qemu-options.hx could be updated. It documents both
> "mem" and "memdev" currently but doesn't tell people that "memdev" is
> the preferred syntax for future usage / warn against using "mem".

Will do so.

> 
> Regards,
> Daniel