11:07 a.m.
On Jan 6, 2017, at 10:48 AM, Jeff Mesnil <jmesnil(a)redhat.com>
wrote:
>
> On 6 Jan 2017, at 17:24, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
>
> Any opinions? This is basically a proposal to provide a formal way of including
warning data in operations responses.
>
> If we did it it would probably be something like:
>
> {
> “outcome”=>”success”,
> “result”=>”foo”,
> “response-headers”=> {
> “warnings”=[
> “blah blah blah”,
> { “some_complex_issue: details”>[“x”,”y”,’z”]}
> ]
> }
> }
We had a similar discussion while implementing :migrate operations for legacy subsystems
and ended up using a "notification-warnings” parameter in the result node (as opposed
to the response-headers node).
Yes. I think that was the right approach there, as those warnings were a pretty
fundamental part of the result of the operation.
>
> Is that last statement enough reason to add this functionality vs just using the
server log to warn, or just not warning at all?
It’s nice to have for sure and would help having a consistent reporting systems in our
management clients (we can imagine having flash warnings in the web console and special
text in the CLI written to syserr for example).
In an ideal world, I think that any WARN logged in the server console that is caused by a
management operation should be reported to the invoker.
I was going to say that the private API usage warnings we log couldn’t fit nicely, as they
are done via MSC threads that don’t know about any management op. But thinking a bit more
I think that’s probably solvable.
I’d go a step further to constrain the warnings model as a dictionary
where each key is a registered logger ID (e.g. XNIO001007) and a value a i18ned string (or
a more complex i18ned structure).
Something like:
{
“outcome”=>”success”,
“result”=>”foo”,
“response-headers”=> {
“warnings” => {
“XNIO00107” => “some thing happens”,
“WFCORE1234” => { “some_complex_issue” => [“x”,”y”,’z”]}
}
}
}
That’d be very helpful to build our knowledge base and report issues.
It would be interesting if there were a nice way to integrate such keys with our existing
i18n message infrastructure. Really we’d have to do that, or else have the keys
unambiguously different from the message ids.
> In theory we could use the same facility to report management API
deprecation warnings back. Doing that might be annoying though. Those are a less serious
problem than this WFCORE-1987 thing.
If you go that way, you could somehow configure the level of reported warnings and let
the admin configure the level of reported warnings:
addResponseWarning(String id, int level, String)
addResponseWarning(String id, int level, ModelNode data)
We now have a nice new core-management subsystem where the admin could change the
reported warning level (defaulting to something corresponding to serious warnings, as
opposed to minor warnings such as API deprecation).
It could be controllable via a request-header as well, allowing clients to declare what
they want, overriding any server-side settings..
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat