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. 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". Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
