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

[romradz at man.poznan.pl]

On Thu, 13 May 2010, romradz at man.poznan.pl wrote:

>
>
> On Thu, 13 May 2010, Piotr Pikusa wrote:
>
>> romradz at man.poznan.pl wrote:
>>>
>>> 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
>>>
>>>
>> But then I suppose we must assume that developer will write a code which is
>> understandable by all others, especially client maintainers or client users.
>> I think that this is strong assumption and can provide to the situation that
>> from two different services the same two errors will have very different
>> result code and a client may then think that those two errors are not the
>> same. Cannot we just follow a standard part of results codes presented by you
>> Roman and then bring together non-standard and include them into NMC? It
>> requires developers` agreement on result codes related to the same errors.
>>
>
> I see your point. So we could define a set of core status codes for
> each service type or/and common status codes. Other result codes would
> only support standard parts, e.g.
>
> http://perfsonar.net/status/informational/something_which_is_proposed_by_service_maintainer_or_owner_and_it_is_not_standard
>
> We could start with LS and MA (mdm service maintainer would propose codes
> for the first and psps service maintainer would do the same for the
> latter). What do you think?


...wait, I think I'm categorizing status codes according to service types 
but we wanted to drop this approach.

Roman