Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Jul 2015 22:31:16 +0200

Tim,

I am not exactly sure what you are missing. In -04 we had this:

   object {
       string              ma-task-name;
       string              ma-task-role;
       uri                 ma-task-registry;
       datetime            ma-task-last-invocation;
       datetime            ma-task-last-successful;
       string              ma-task-last-successful-message;
       datetime            ma-task-last-failed;
       string              ma-task-last-failed-message;
      [ma-condition-obj    ma-task-conditions<0..*>];
   } ma-task-status-obj

   object {
     int                   ma-condition-code;
     string                ma-condition-text;
   } ma-condition-obj

It was unclear what this means. What are the N ma-condition-objs
associated to a task representing? So we clarified it by reporting the
status code together with the last completion and the last failed
completion. Hence we now have this:

     object {
         string              ma-task-name;
         uri                 ma-task-registry-entries<1..*>;
         [string             ma-task-role<0..*>;]
         datetime            ma-task-last-invocation;
         datetime            ma-task-last-completion;
 ==>     int                 ma-task-last-status;
         string              ma-task-last-message;
         datetime            ma-task-last-failed-completion;
 ==>     int                 ma-task-last-failed-status;
         string              ma-task-last-failed-message;
     } ma-task-status-obj;

We also had M ma-condition-objs associated with the MA itself.

   object {
       uuid                    ma-agent-id;
       urn                     ma-device-id;
       string                  ma-hardware;
       string                  ma-firmware;
       string                  ma-version;
       ma-interface-obj        ma-interfaces<0..*>;
       ma-task-capability-obj  ma-supported-tasks<0..*>;
       datetime                ma-last-started;
      [ma-condition-obj        ma-conditions<0..*>;]
      [ma-task-status-obj      ma-task-status<0..*>;]
   } ma-status-obj;

Again, it is unclear what these would be and report. So we removed
them and now we have this instead:

     object {
         uuid                    ma-agent-id;
         uri                     ma-device-id;
         string                  ma-hardware;
         string                  ma-firmware;
         string                  ma-version;
         ma-interface-obj        ma-interfaces<0..*>;
         datetime                ma-last-started;
        [ma-task-status-obj      ma-task-status<0..*>;]
     } ma-status-obj;

Does this explanation make sense? If not, can you explain what you
thought the previous definitions would contain?

/js

On Fri, May 15, 2015 at 12:07:25PM +0000, Carey, Timothy (Timothy) wrote:
> Juergen,
> 
> Any idea on why the task capabilities and conditions were removed from the MA status in the information model?
> 
> Thanks,
> Tim
> 
> From: Carey, Timothy (Timothy)
> Sent: Monday, May 11, 2015 2:33 PM
> To: [email-masked]
> Subject: draft-ietf-lmap-information-model-05: MA task capabilities
> 
> Team,
> 
> I was reviewing draft-ietf-lmap-information-model-05 and had a question on the what happened to the task capabilities and conditions as part of the MA status. The text is still in the draft but the elements are gone...
> 
> Any help would be appreciated
> 
> Thanks,
> Tim
> 

> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

-- 
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: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Mon, 6 Jul 2015 12:15:29 +0000

Juergen,

The conditions associated with the task where when this task was executed what were the conditions (possibly things like WAN link down, not enough memory for the task to execute, cross traffic occurred during the task) that resulted in the task's status.

Likewise in the MA - the conditions are the conditions of the MA at the time of retrieval (e.g., unable to connect to collector).

At first we had certain conditions spelled out in the information model but we moved them in "generic" implementation specific conditions.

Finally the supported tasks are simply the tasks (tests) that the MA is able to execute (name, role and URI of the registry). A controller will need to know this in order to ask a MA to execute a task.

Hope that helps,

Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, July 02, 2015 3:31 PM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities

Tim,

   object {
       string              ma-task-name;
       string              ma-task-role;
       uri                 ma-task-registry;

   object {
     int                   ma-condition-code;

It was unclear what this means. What are the N ma-condition-objs associated to a task representing? So we clarified it by reporting the status code together with the last completion and the last failed completion. Hence we now have this:

     object {
         string              ma-task-name;

   object {
       uuid                    ma-agent-id;
       urn                     ma-device-id;
       string                  ma-hardware;
       string                  ma-firmware;
       string                  ma-version;

Again, it is unclear what these would be and report. So we removed them and now we have this instead:

     object {
         uuid                    ma-agent-id;
         uri                     ma-device-id;
         string                  ma-hardware;
         string                  ma-firmware;
         string                  ma-version;

Does this explanation make sense? If not, can you explain what you thought the previous definitions would contain?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jul 2015 14:29:03 +0200

> The conditions associated with the task where when this task was executed what were the conditions (possibly things like WAN link down, not enough memory for the task to execute, cross traffic occu…

But is this not captured in ma-task-last-status / ma-task-last-message
and ma-task-last-failed-status / ma-task-last-failed-message?
 
> Likewise in the MA - the conditions are the conditions of the MA at the time of retrieval (e.g., unable to connect to collector).

In the new model, would this not simply be reported as a task failure?
What are the MA specific conditions? We had in another thread a
proposal to have an MA status object. What else would be needed?
Perhaps we are fine if we can get number of states defined that we
need to distinguish.

> Finally the supported tasks are simply the tasks (tests) that the MA is able to execute (name, role and URI of the registry). A controller will need to know this in order to ask a MA to execute a t…

Yes, this makes sense. But it does not feel right to associate status
codes returned by actions with the static task list that serves as an
inventory - they IMHO should be associated with actions.

/js

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Mon, 6 Jul 2015 12:39:56 +0000

Juergen,

<TAC> inline

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 7:29 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities

> The conditions associated with the task where when this task was executed what were the conditions (possibly things like WAN link down, not enough memory for the task to execute, cross traffic occu…

But is this not captured in ma-task-last-status / ma-task-last-message and ma-task-last-failed-status / ma-task-last-failed-message?
<TAC> No their can be many conditions that result in say a failed task. These string messages are singleton

In the new model, would this not simply be reported as a task failure?
What are the MA specific conditions? We had in another thread a proposal to have an MA status object. What else would be needed?
Perhaps we are fine if we can get number of states defined that we need to distinguish.
<TAC> Again there are times when there are multiple conditions that feed into the current status of an MA. I think if you have a MA operational status it should be fine but I would like to hear what others think.

> Finally the supported tasks are simply the tasks (tests) that the MA is able to execute (name, role and URI of the registry). A controller will need to know this in order to ask a MA to execute a t…

Yes, this makes sense. But it does not feel right to associate status codes returned by actions with the static task list that serves as an inventory - they IMHO should be associated with actions.

<TAC> Yes you are correct that status should be associated with the last action executed for task - which is why the names were "last" - they only wanted the "last" action.  We can certainly make that more clear if it isn't. In my model the description has it as the last status update of a scheduled action that referenced this task....

/js
 
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jul 2015 14:46:02 +0200

> <TAC> No their can be many conditions that result in say a failed task. These string messages are singleton

This is not an inventory of conditions but the specific condition that
lead to a failure.

> <TAC> Yes you are correct that status should be associated with the last action executed for task - which is why the names were "last" - they only wanted the "last" action.  We can certainly make t…

The same task may be run from several different schedules and hence we
loose information. Only one of them might lead to failures but if it
is not clear which one, how do you debug this?

/js