[libvirt] [RFC 0/7] Warn at runtime when deprecated features are used

Pavel Hrdina phrdina at redhat.com
Thu Oct 4 13:03:08 UTC 2018


On Thu, Oct 04, 2018 at 02:06:54PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-10-04 at 13:36 +0200, Pavel Hrdina wrote:
> > Runtime deprecation warning in C code is wrong in my opinion and even
> > though there are some project doing it we should not do it.
> > Deprecation warning is for developers, not for users.
> > 
> > Yes, adding deprecation warning into libvirt will not solve the goal for
> > oVirt nor OpenStack, but this should be handled in the libvirt-python
> > binding code using language-specific manner as Andrea mentioned above.
> > In python it happens to be a runtime warning,
> > warnings.DeprecatedWarning, however, that warning is by default ignored
> > unless it's triggered from __main__, so developers using libvirt-python
> > API would need to enable that warning for their test-suite, that's a
> > python way how to do it.
> > 
> > One of the reasons why it's not enabled by default is that as user
> > you have no way how to modify the module code and therefore you should
> > not get the warning.  From user point of view everything works how it
> > should and I don't care whether my program uses something deprecated 
> > or not.  It's unnecessary noise for the user.
> 
> All of the above is perfectly reasonable if you only consider cases
> where we might want to deprecate an entire API, but fails to take
> into account that a large part of libvirt's functionality is exposed
> through XML elements and attributes rather than C function calls.
> 
> So if we wanted to warn people that not providing a machine type
> when defining a guest is a bad idea and they should use libosinfo
> to figure out the information instead, there's simply no way we can
> do that at compile time.

Sure, if we want to warn about missing/wrong/deprecated features from
XML we need runtime warnings only for that and that's OK, that is
something that user usually can change.

> Not to mention that the existence of virsh somewhat blurs the lines
> between users and developers, as it's a very thin wrapper where each
> option translates almost directly to the corresponding C function
> call and its parameters and flags, but is then installed in $PATH
> for the world to use...

Again if it's something XML related user can change that even while
using virsh, if it's API related user should not see it by default.

> > > And for dropping functionality - we can not do that. Period.
> > 
> > +1, for everyone questioning this please read [1], thanks.
> > 
> > [1] <https://libvirt.org/support.html>
> 
> As mentioned elsewhere, that document defines our current stance on
> backwards compatibility, but nothing says we can't change it if we
> think doing so will bring benefits to developers and users, which I
> strongly believe it would.
> 
> We used to have a similar, although not formally documented, stance
> on supporting old QEMU versions, but we've since relaxed it[1] which
> has benefited libvirt and its developers greatly without, as far as
> I'm aware, inconveniencing users.

I'm not sure whether we had that promise for QEMU versions documented
and it's also slightly different situation.  We are dropping support
for old QEMUs in new libvirts with the assumption that user usually
updates both at the same time (through OS distribution channels).

Removing APIs is totally different.  We would have to bump our library
so version and that would break every existing application unless you
would rebuild it to use the new library.  That would cause a lot of
issues for everyone using libvirt.

Yes, dropping old or broken API would allow us to drop a lot of code,
on the other hand with the deprecation warning in place and deprecation
note in the documentation we can start claiming that these APIs are no
longer supported and any bugs caused be these APIs (maybe except for
security issues) will not be fixed and in the code we could try to
isolate that code as much as possible to make it easier for us.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20181004/f29ed7f9/attachment-0001.sig>


More information about the libvir-list mailing list