On 8/29/19 11:59 AM, Christophe de Dinechin wrote:
John Snow writes: [...]
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.
I like this approach even if there is no consumer today. It does not hurt, and it is indeed a motivation to develop consumers that care.
I personally find this much easier to swallow than any kind of crash on deprecation, which already at the BoF seemed like a really big hammer to kill a fly.
CC'ing Andrea as well, because we discussed recently about how to deal with error checking in general, and if a new error checking framework is being put in place, adding deprecation to the thinking could be a good idea.
The most convincing argument against deprecation notices like this is not that they won't be consumed, but that they are difficult to plumb through the C infrastructure. Sadly, I think I have to agree there -- we can't even really model it like hints, because these are cases where there was no /error/ but instead a success -- but our error propagation doesn't work on those terms generally and we'd need a rather extensive audit to allow warnings. We could always fudge it with a kind of global warning log: clear the log at the beginning of a QMP interaction and if the log is non-empty when we return, amend the return with that information. That's not really the nicest thing to do in a multi-process, multi-threaded, multi-stacked application, though, so... --js