Re: [libvirt] [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters

Am 15.08.2019 um 18:07 hat John Snow geschrieben: > On 8/15/19 6:49 AM, Kevin Wolf wrote: >> Am 14.08.2019 um 21:27 hat John Snow geschrieben: >>> >>> This might be OK to do right away, though. >>> >>> I asked Markus this not too long ago; do we want to amend the QAPI >>> schema specification to allow commands to return with "Warning" strings, >>> or "Deprecated" stings to allow in-band deprecation notices for cases >>> like these? >>> >>> example: >>> >>> { "return": {}, >>> "deprecated": True, >>> "warning": "Omitting filter-node-name parameter is deprecated, it will >>> be required in the future" >>> } >>> >>> There's no "error" key, so this should be recognized as success by >>> compatible clients, but they'll definitely see the extra information. >>> >>> Part of my motivation is to facilitate a more aggressive deprecation of >>> legacy features by ensuring that we are able to rigorously notify users >>> through any means that they need to adjust their scripts. >> >> Who would read this, though? In the best case it ends up deep in a >> libvirt log that nobody will look at because there was no error. In the >> more common case, the debug level is configured so that QMP traffic >> isn't even logged. >> >> Kevin >> > > I believe you are right, but I also can't shake the feeling that this > attitude ensures that we'll never find a way to expose this information > to the end-user. Is this not too defeatist? I think the discussed approach that seemed most likely to me to succeed was adding a command line option that makes QEMU just crash if you use a deprecated feature, and enable that in libvirt test cases (or possibly even any non-release builds, though maybe it's a bit harsh there). > I think deprecation notices in the QMP stream has two benefits: > > 1) Any direct usages via qmp-shell or manual JSON connection are likely > to see this message in development or testing. I feel the usage of QEMU > directly is more likely to increase with time as other stacks seek to > work around libvirt. > > [Whether or not they should is another question, but I believe the > current reality to be that people are trying to.] I don't know about other people, but as a human user, I don't care about deprecation notices. As long as something works, I use it, and once I get an error message back, I'll use something else. If I manually enter drive_mirror and get a warning back, that doesn't tell me that libvirt still does the same thing and needs to be fixed. It just tells me that in the future I might need to change the commands that I use manually.

I guess this would still prevent adding new libvirt features that build on deprecated QEMU features because some manual testing will be involved there. But was this ever a problem?

> 2) Programmatic deprecation notices can't be presented to a user at all > if we don't send them; at least this way it becomes libvirt's problem > over what to do with them. Perhaps even just in testing and regression > suites libvirt can assert that it sees no deprecation warnings (or > whitelist certain ones it knows about.) > > In the case of libvirt, it's not even necessarily about making sure the > end user sees it, because it isn't even necessarily the user's fault -- > it's libvirt's. This is a sure-fire programmatic way to communicate > compatibility changes to libvirt. If libvirt uses this to make test cases fail, it could work.

Kevin