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

[Piotr Pikusa]

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.