On Fri, Oct 05, 2018 at 12:33:57PM +0200, Jiri Denemark wrote: > On Fri, Oct 05, 2018 at 09:54:02 +0100, Daniel P. Berrangé wrote: > > On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote: > > > On Thu, Oct 04, 2018 at 14:13:41 +0100, Daniel P. Berrangé wrote: > > > > The problem with saying applications were doing it "wrong" is that > > > > this definition of "wrong" changes. Applications were perfectly > > > > justified in not providing a machine type, because the concept > > > > didn't even exist in earlier libvirt. Once it did exist, we still > > > > only supported x86, and there was no q35, so it was still valid to > > > > not specify it. > > > > > > > > Even today it is reasonable to not care about machine type in case > > > > where the app only cares about x86. > > > > > > > > Our view of "best" way to configure a guest is changing and in many > > > > cases it is becoming increasingly clear that there's no single > > > > "best" way, or no single perfect default. > > > > > > As I tried to explain in another mail in this thread, I definitely agree > > > we should not change defaults just because we think some value is better > > > now. That's really a job for libosinfo. > > > > > > 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. > > > > It is not the kind of think an application will dynamically take > > action on at runtime. It is something application developers need > > to be told about so they can adapt future code releases as needed. > > OK, but if it's us choosing some default which QEMU considers > deprecated, it's us who should dealt with it. That is, change the > default IMHO. Sure apps could just stop relying on defaults and choose > something specific which is not deprecated, but that doesn't mean we as > a user of QEMU should continue using default values which got deprecated > and are likely to be removed. > > If it's something which is not user/guest visible, we are already trying > to move to more modern interfaces. That is easy since it doesn't change > anything for libvirt users, but I feel like we need to have a plan for > stuff which actually is visible to our users. If some user visible feature is actually removed, then our hand is forced - we have to pick something else to replace it. This is what happened with the default NIC with RHEL stopped building rtl8139, so we had to have a default fallback. That change is/was not seemless since there exist OS which supported rtl8139 but which lacked e1000 / virtio-net drivers. Fortunately apps already use libosinfo to explicitly set NIC model so the breakage was not so visible. If 'i440fx' is ever actually deleted we would have todo something similar - prefer i440fx for best historical compat, but fallback to q35 despite knowing it could break. > > > So taking "q35" as an example, if QEMU marks i440fx machine types as > > > deprecated (they seem to be thinking about it) I don't see that big > > > difference[*] in changing the default machine type to "q35". After all > > > we will automatically change the default once i440fx is removed > > > completely. > > > > There's no active plans to deprecate or remove i440fx upstream in > > QEMU. If a downstream did remove it, then clearly that'll impose > > some level of pain on applications. > > I wasn't talking about downstream and I probably gave a wrong example > and mixed several different things, but the point stays valid. We should > have some sort of a policy when and how we change default values rather > than saying "we never do that except when we already did so". One of the > reason why we store chosen defaults in domain XML is to be able to > change the defaults without breaking existing domains. We should > formally touch this area in our "Support guarantees" document > (https://libvirt.org/support.html) so that users/apps know what they can > expect and we don't have to think or fight everytime someone comes up > with an idea to change a default value. I guess we should outline the NIC default choice as an example of the approach we would take. 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
