9:49 a.m.
On Thu, 2018-10-04 at 14:13 +0100, Daniel P. Berrangé wrote:
On Tue, Oct 02, 2018 at 06:26:12PM +0200, Andrea Bolognani wrote:
> However, libvirt's own default for x86_64 guests' network devices is
> rtl8139, which means that if I later 'virsh edit' the guest or 'virsh
> attach-device' a new network interface I will get that model instead
> of virtio; to add insult to injury, the above will happen even if my
> QEMU binary has rtl8139 compiled out and virtio-net-pci compiled in!
That's not correct actually. If rtl8139 is missing in QEMU, libvirt
will try e1000, and if that's missing it'll try virtio-net.
Welp, you're right. Quite embarrassing that I got it wrong, too,
considering that I am the one who implemented this behavior in the
first place O:-)
The larger point still stands, though: you pretty much never want
to see an rtl8139 device popping up in your guest these days, and
yet it's awfully easy for that to happen which, in my opinion, is
a problem we should address.
> > We can also consider using what qemu provides as a default.
Users will
> > get the default they asked for. They always can specify their specific
> > type if their software is not happy with it.
>
> Using QEMU's default machine type is exactly what we were doing until
> very recently, but we changed that because QEMU's default has been
> i440fx for so long that applications have come to rely on it and
> would break if q35 suddenly started showing up instead, which goes to
> show that they should not have been relying on either QEMU's or
> libvirt's default, and they should have been providing the machine
> type explicitly, possibly as obtained by querying libosinfo, instead.
>
> Or, looking at it from the other side, that libvirt should have
> required them to provide the machine type instead of trying to be
> helpful and filling it in if absent. We can't retroactively mandate
> applications do that, but we can deprecate such behavior and thus
> steer them firmly towards the proper solution.
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.
Sure, that design decision made complete sense in the context it
was made in.
But the context has changed in a way that turned it from an asset
into a liability, and pretending that's not the case will certainly
not solve the issue.
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.
I completely agree here.
Taking something that's historically optional and saying it
should
be mandatory is a defacto API breakage. Deprecating it doesn't
magically stop it being an API breakage. It is just giving apps
a warning that we're about to hurt them, and I don't consider that
a good thing.
I disagree: for better or worse, features being deprecated and
ultimately removed is one of the realities of software development,
and I see very little motivation for libvirt to try and play by
different rules.
I think we're largely missing the bigger picture here.
Configuring
guests, and using libvirt APIs in general, can be very complicated.
We provide basic API contract docs, and a crude XML schema reference,
but this is woefully insufficient. There's very little telling apps
about the big picture way to configure things / implement tasks.
We're missing a good developer guide where you'd give info to apps
devs about how to effectively use libvirt, so it is no surprise that
apps do things that are sub-optimal. Providing better docs to app
devs would be far more useful than deprecation warnings which have
minimal contextual guidance.
I agree that having better documentation would help, and we should
definitely work towards that goal.
However, I'm fairly confident trying to address issues through
documentation only will not be enough to get applications off
problematic API usage: people mentioned several times elsewhere in
the thread how they think *emitting warnings* itself wouldn't be
enough, and developers would only take notice once the application
breaks for good! How is documentation going to be effective? Who
would look at documentation periodically just to make sure they're
not using features that have since been deprecated? I know I don't
do that for any of libvirt's dependencies, but if I started getting
warnings I'd certainly take notice.
Unless users are nagged about it during usage and developers are
nagged about it during development, usage of problematic APIs will
never go away.
--
Andrea Bolognani / Red Hat / Virtualization