On 8/15/19 12:48 PM, Kevin Wolf wrote:
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.
That the message we return needs to be *useful* doesn't sound like a count against it.
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?
No, because until recently we didn't deprecate anything.
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.
Yeah, I think there's solid use there. I'll continue along in Markus's thread.
Kevin