[Nmc-wg] Result codes in MDM RRD MA and LS - action from last conf call

[romradz at man.poznan.pl]

On Tue, 11 May 2010, Jason Zurawski wrote:

> Hi Piotr;
>
> On 5/11/10 10:26 AM, Piotr Pikusa wrote:
>> Hi Jason!
>> 
>> Jason Zurawski wrote:
>>> RRDMA:
>>> 
>>> - Are these only for the perfSONAR layer, or do these cover other
>>> exceptions that may come up from tomcat/axis/exist?
>> 
>> Those result codes, which were sent present only perfSONAR layer. If
>> some exception comes from eXist it is covered by perfSONAR code. However
>> presented list doesn't cover tomcat and axis errors if they appear
>> besides the perfSONAR code and cannot be catch by it.
>> 
>>> - I only see one that uses the 'error.' format:
>>> "error.common.storage.xmldb.open". Are these all 'error's or are some
>>> of them 'success' too?
>>> 
>> Success is only responded by echo request and has a url format. When
>> other requests are completed successfully just a proper message with
>> requested data is sent without any success code and I suppose it is
>> compatible with nmc-wg standard for MA services.
>>> - There is a lot of reuse of 'query_exception'. In the new model would
>>> that still be the case or would there be more specific new error codes
>>> used?
>>> 
>> Does not it come out from new results code - the clienterror and
>> servererror part in the tree?
>
>
> I am not sure what you mean by 'clienterror' or 'servererror' in this case 
> because we still don't have a complete mapping of how you think all of the 
> old result codes will translate into new.  I would expect that this is the 
> next step (we can talk about this on the thursday call).
>
> Maybe I wasn't clear enough on my question.  From the examples that I am 
> reading for 'query_exception' it covers several cases:
>
> - Structure of the message may be wrong, e.g. "no data trigger", "no subject 
> element in metadata id=[...]"
> - Content in XML is unexpected, e.g. "eventType [...] in metadata id= [...] 
> is not supported"
> - Content is 'wrong' (not sure how to interpret this, maybe its unexpected 
> or maybe it is just incorrect vs. what is stored in the backend?), e.g. 
> "wrong ipAddress", "wrong hostName"
>
> I would call these things different error messages since they cover slightly 
> different cases.
>
> My original question was do you or Roman envision these translating directly 
> to a single result code in the new model, or would these be encoded as 
> different codes for different situations.

Moving to the new model will be difficult because meanings of errors
may overlap. Let's take 3 examples mentioned above. We can assign them to

clienterror/bed_request, clienterror/event_type_not_allowed, 
clienterror/not_acceptable

but this one:

clienterror/bed_request, clienterror/event_type_not_allowed,
clienterror/bed_request

also provides true info about error situations.


I'm thinking that maybe we should say that the first part of result code 
URL is standard but the second part is not controled by NMC.


Standard parts of result codes:
   http://perfsonar.net/status/informational/
   http://perfsonar.net/status/successful/
   http://perfsonar.net/status/redirection/
   http://perfsonar.net/status/clienterror/
   http://perfsonar.net/status/servererror/

Example of complete result code:
   http://perfsonar.net/status/informational/something_which_is_proposed_by_service_maintainer_or_owner


Cheers,
Roman