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

Fri May 14 10:37:57 CDT 2010

Hi All;

Comments down below on a couple of things:

> romradz at man.poznan.pl wrote:
>>
>>
>>
>> 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
>>>>>

As discussed on the call - overlap is bound to happen.  I think the 
right way to go forward is to try to perform the mapping of the current 
codes into the new tree.  If things map into multiple spaces then we 
note that.  We can always go back later and try to make the 'correct' 
decision where things should land.  We just need a place to start.

As for the example above where the developer has control over the 'last' 
stanza of the code - I think this is the wrong thing to do.  The whole 
point of standardizing the codes to eliminate this.

Thanks;

-jason

>>>>> 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
>>
>>
>
>
> Maybe we can't? That was good proposal but when we want to make it real
> it occurs non-implementable for now? I'm afraid of having some not
> documented result codes. We can implement this list which is written in
> your previous e-mail and then follow some non-standard result codes
> related to particular service type but without writing its type in the
> result code. It would be like this:
>
> http://perfsonar.net/status/informational/MA_Information
> http://perfsonar.net/status/informational/LS_Information
> http://perfsonar.net/status/informational/Common_Information_for_LS_and_MA
>
> but we should avoid something like this
> http://perfsonar.net/status/informational/MA/Information
> http://perfsonar.net/status/informational/LS/Information
>
> because of previous discussion about it which shown that this is
> redundant solution.
>
> In this approach we can follow your idea about definitions non standard
> and also common result codes in NMC.
>
>
> Piotr