Subject: [lmap] status codes aka condition codes

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 19:53:04 +0100

Hi,

to achieve interoperability, I think we need to define concrete status
codes (aka condition codes), e.g. for runtime errors such as
"measurement task could not be started", "measurement task aborted
abnormally", etc. There are two options:

a) We define a set of status codes as part of the information model.
   + Different LMAP implementations that comply to the same
     information model will use the same status codes.
   - The downside is that we have to nail them down now.

b) We define a set of status codes as part of the data models.
   - Different protocols complying to the information model
     will use different status codes.
   + We can postpone the work needed to work out the essential
     status codes.

If we decide for option b), I like to request that note is added to
the information model that data models are expected to define a set of
well-known status codes (aka condition codes) and that they may be
encoded in something different than a string (that is the type used in
the data model is more acting like a placeholder).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Feb 2015 12:43:35 +0100

> the data model is more acting like a placeholder).

I have thought a bit more about this.

My understanding is that the information / data models talk about the
status code returned by the task. I think this should be modeled as an
int since this is how most operating systems deal with it. And it
seems most systems interpret 0 as successful termination. There may be
limitations for status codes outside the range 0..255.

My further understanding is that runtime failures of the software
component starting tasks etc. are handled via the logging mechanism.
While looking it up, I found that ma-log-obj has a field ma-log-code
of type 'code' - whatever that is. ;-)

Summary: In the information model, I suggest to change
ma-condition-code from string to int (perhaps adding text about the
number range from above). In the YANG data model, we will then
make a corresponding change.

/js