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

[Juergen Schoenwaelder <[e-mail]>]

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

On Thu, Jan 05, 2017 at 09:32:43AM +0000, Carey, Timothy (Nokia - US) wrote:
> 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:[e-mail]] 
> Sent: Wednesday, January 04, 2017 4:46 PM
> To: Carey, Timothy (Nokia - US) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [lmap] /capabilities/task* vs /capabilities/tasks/task*
> 
> On Tue, Jan 03, 2017 at 08:27:37PM +0000, Carey, Timothy (Nokia - US) wrote:
> > Juergen,
> > 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
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>