On Fri, Oct 05, 2018 at 11:38:14AM +0200, Andrea Bolognani wrote: > On Fri, 2018-10-05 at 09:54 +0100, Daniel P. Berrangé wrote: > > On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote: > > > But what if QEMU (or any other hypervisor) marks something (device > > > model, machine type) as deprecated and we use that deprecated value as > > > our default. Shouldn't we be able to tell about it to our users (here > > > runtime warnings could help) when they use such thing explicitly and > > > choose a different default value? That would help users with the > > > transition and once hypervisor drops support for it completely, fewer > > > existing domains will be affected since the recently created ones would > > > already use non-deprecated defaults. > > > > QEMU already emits warnings on stderr whenever something that is > > deprecated is used, and those end up in the libvirt log file for > > that guest. I don't think that we need to duplicate what QEMU > > is already reporting again. > > Warnings printed on stderr -> users and developers will actually > see them, be annoyed by them, eventually cave in and act upon them. > > Warnings written to a log -> nobody will notice them, until one day > things suddenly stop working apparently out of the blue. > > We might pretend that's not the case, but really, it is. You cannot expect that libvirt will duplicate all the deprecation warnings from all hypervisors for all models or machine types or other values that can be set to a lot of different attributes in our XML. Once we do that for machine type there will be requests to do it for other attributes as well. I think that this is a big NO and way out of scope of libvirt. Pavel
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
