Subject: [lmap] /capabilities/task* vs /capabilities/tasks/task*

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jan 2017 17:32:23 +0100

While implementing the /capabilities, I discovered that we do not have
a node representing the whole task list in the capabilities branch,
i.e., the tasks all appear right below /capabilities. I think it would
be simpler and more consistent with all other lists we have if we
would have a have tasks appear below /capabilities/tasks. (It would
also make sense to move /capabilities before any configuration
branches.)

It is also a bit unclear how capability tasks and configured tasks
work together. Right now, I can set the program property on both.
Would it not be more natural to have the program set only on the
capability and a configured task can only reference a capability task?
Right now the behaviour is not really clear; I can try to configure a
task to run any program, which is likely not what we want. Perhaps the
idea is that I can only configure a program listed in the capability
tasks. Perhaps we should instead have a way to reference a capability
task from a task configuration (and if the reference can't be
resolved, the referencing task (and any other indirect references to
the referencing task) would not be applied config. Well, what we have
may be possible to implement in a reasonable way, even though the
details may be not entirely obvious.

/js

PS: I do not really know where the chairs think we are with the LMAP
    documents in their lifecycle. I have implemented what I described
    in the first paragraph in my sources, see the diff here:

    http://www.beadg.de/lmap/draft-ietf-lmap-yang-10-from-09.diff.html

-- 
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 (Nokia - US)" <[email-masked]>
Date: Tue, 3 Jan 2017 20:27:37 +0000

Juergen,
The task capabilities just point to the registry objects (registry and roles) - they don't have programs assigned.

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, January 03, 2017 10:32 AM
To: [email-masked]
Subject: [lmap] /capabilities/task* vs /capabilities/tasks/task*

While implementing the /capabilities, I discovered that we do not have a node representing the whole task list in the capabilities branch, i.e., the tasks all appear right below /capabilities. I think it would be simpler and more consistent with all other lists we have if we would have a have tasks appear below /capabilities/tasks. (It would also make sense to move /capabilities before any configuration
branches.)

It is also a bit unclear how capability tasks and configured tasks work together. Right now, I can set the program property on both.
Would it not be more natural to have the program set only on the capability and a configured task can only reference a capability task?
Right now the behaviour is not really clear; I can try to configure a task to run any program, which is likely not what we want. Perhaps the idea is that I can only configure a program listed in the capability tasks. Perhaps we should instead have a way to reference a capability task from a task configuration (and if the reference can't be resolved, the referencing task (and any other indirect references to the referencing task) would not be applied config. Well, what we have may be possible to implement in a reasonable way, even though the details may be not entirely obvious.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Jan 2017 23:45:56 +0100

> The task capabilities just point to the registry objects (registry and roles) - they don't have programs assigned.

In the information model; the data model also allows to have entries
without a registry object which identifies a program to run (and this
is what I have implemented).

The question, however, is what exactly happens if a configured task
refers to a capability task that does not exist. There are different
options:

a) The configuration is invalid. This is problematic in a YANG context
   since the idea is that validity of a configuration should not
   depend on the specific runtime capabilities of a system.

b) The configuration may be valid but of configured tasks that refer
   to tasks that are not among the capabilities are not executed.

>From a YANG perspective, semantics b) seem to make most sense. But
then the question is how this plays with actions (that refer to
configured tasks) and schedules (that refer to actions). There are
again differnet options:

b1) An action that refers to a configured task that references a
    non-existing capability is simply not executed.

b2) Any schedule that includes an action that that refers to a
    configured task that references a non-existing capability is not
    executed.

Recall that we have differnet execution modes. For pipelines
schedules, b2) might make sense, for parallel or sequential schedules
b1) might make sense.

>From the discussion around intended and applied configs, it seems b2
seems to make most sense because b2) essentially says that any actions
and their schedules that reference non-existing capabilities are not
part of the applied config, that is, the applied config becomes a
proper subset of the schedules (and not a subset of the actions of the
schedules).

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Thu, 5 Jan 2017 09:32:43 +0000

Juergen,

I would agree that option B is the correct approach - but the action should fail, correct?

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, January 04, 2017 4:46 PM
To: Carey, Timothy (Nokia - US) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lmap] /capabilities/task* vs /capabilities/tasks/task*

> The task capabilities just point to the registry objects (registry and roles) - they don't have programs assigned.

In the information model; the data model also allows to have entries without a registry object which identifies a program to run (and this is what I have implemented).

The question, however, is what exactly happens if a configured task refers to a capability task that does not exist. There are different
options:

>From a YANG perspective, semantics b) seem to make most sense. But then the question is how this plays with actions (that refer to configured tasks) and schedules (that refer to actions). There are again differnet options:

Recall that we have differnet execution modes. For pipelines schedules, b2) might make sense, for parallel or sequential schedules
b1) might make sense.

>From the discussion around intended and applied configs, it seems b2 seems to make most sense because b2) essentially says that any actions and their schedules that reference non-existing capabilities are not part of the applied config, that is, the applied config becomes a proper subset of the schedules (and not a subset of the actions of the schedules).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jan 2017 15:41:47 +0100

Yes, one option is to simply have actions fail that refer to a
capability that is not available. This also seems to be the simplest
to implement.

/js