From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gG2ic-0001V5-BV for qemu-devel@nongnu.org; Fri, 26 Oct 2018 10:04:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gG2iZ-0003ZE-4g for qemu-devel@nongnu.org; Fri, 26 Oct 2018 10:04:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44656) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gG2iY-0003Yk-Ru for qemu-devel@nongnu.org; Fri, 26 Oct 2018 10:04:03 -0400 From: Markus Armbruster Date: Fri, 26 Oct 2018 16:03:51 +0200 Message-ID: <87mur0ls8o.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Alberto Garcia , Andrea Bolognani , Christophe de Dinechin , =?utf-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Eduardo Habkost , Laine Stump , Laurent Vivier , Peter Krempa , Pino Toscano , Thomas Huth This is from my (imperfect) notes, corrections welcome. Motivation: QEMU contains stuff of dubious value, which gets in the way in various (sometimes painful and expensive) ways. Deprecation is the marking of an external interface as "we intend to remove this, you should stop using it" (preferably with advice on what to use instead). We have a deprecation policy to guide us through this process. Topics we covered, reordered for readability: * Dropping features inconveniences their users. Keeping them impedes forward movement, and thus inconveniences other users. We need to engage with the tradeoffs. * The cost of keeping both old and new for a deprecation grace period (currently two releases) can be painfully high. Tradeoff again. However, there's rough consensus not to mess with the deprecation policy right now. * When something has been broken for the customary deprecation grace period, removing it without going through the deprecation process should be okay. * We may have to deprecate interfaces, but we may also have a need to deprecate guarantees interfaces provide. Worse when the guarantees are tacit. No good answers. Let's attack less thorny problems first. * One obvious class of candidates for removal is machines we don't know how to boot, or can't boot, say because we lack required firmware and/or OS. Of course, "can boot" should be an automated test. As a first step towards that, we should at least document how to boot each machine. We're going to ask machine maintainers to do that. * We need to communicate "you're using something that is deprecated". How? Right now, we print a deprecation message. Okay when humans use QEMU directly in a shell. However, when QEMU sits at the bottom of a software stack, the message will likely end up in a log file that is effectively write-only. - The one way to get people read log files is crashing their application. A command line option --future could make QEMU crash right after printing a deprecation message. This could help with finding use of deprecated features in a testing environment. - A less destructive way to grab people's attention is to make things run really, really slow: have QEMU go to sleep for a while after printing a deprecation message. - We can also pass the buck to the next layer up: emit a QMP event. Sadly, by the time the next layer connects to QMP, plenty of stuff already happened. We'd have to buffer deprecation events somehow. What would libvirt do with such an event? Log it, taint the domain, emit a (libvirt) event to pass it on to the next layer up. - A completely different idea is to have a configuratin linter. To support doing this at the libvirt level, QEMU could expose "is deprecated" in interface introspection. Feels feasible for QMP, where we already have sufficiently expressive introspection. For CLI, we'd first have to provide that (but we want that anyway). - We might also want to dispay deprecation messages in QEMU's GUI somehow, or on serial consoles.