On Mon, 4 Mar 2019 15:02:18 +0000 Daniel P. Berrangé <berrange@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
