Re: [netmod] Action and RPC statements

[Andy Bierman <[e-mail]>]

On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer <[e-mail]> wrote:

> Sorry, if I wasn't clear.  I meant the <datastore> element would
> be directly under <action>, so the system knows where to start
> looking for data.  Guessing is bad.
>
>
Totally agree guessing is bad.
Did you see the <action2> proposal in a previous email?
That is exactly what I proposed, except I do not want to
overload <action> so the new template would be a different name.

I realize the expanded name of the datastore element prevents it from
being confused with top-level YANG nodes, but the conformance
is more clear with a new name.




> Thanks,
>  Phil
>

Andy


>
>
> Andy Bierman writes:
> >So a server will be required to guess the correct datastore until it
> >finds the right one that matches the action instance?
> >
> >   <action>
> >       <top>
> >          <list1>
> >             <key>10</key>
> >             <do-test>
> >                <datastore>candidate</datastore>
> >             </do-test>
> >          </list1>
> >        </top>
> >    </action>
> >
> >The server will guess the datastore in some proprietary order and parse
> >instances of /top/ and /top/list1.  Then it finds the <do-test> action
> >and parses the input to get to the datastore and find out the real
> datastore
> >to use.  If the server guessed wrong, then it reparses the <action>
> against
> >the requested datastore.  Hopefully the schema trees match up.
> >
> >Will vendors do all the extra work required to support this sort of thing?
> >I doubt it.
> >
> >
> >Andy
> >
> >
> >
> >
> >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer <[e-mail]> wrote:
> >
> >> Robert Wilton writes:
> >> >ii) However, as far as I can see, it doesn't make sense for an action
> to
> >> >directly affect the contents of any configuration datastore, that
> should
> >> >be done via a purpose built rpc (like edit-config).
> >>
> >> An example action would be to retrieve the  fingerprint of an ssh
> >> key.  I might want to get the fingerprint of a key in <candidate>
> >> before I commit it.
> >>
> >> Or I could have an action that sets the SNMPv3 auth key to a random
> >> value, and I want to invoke that action against <candidate>.
> >>
> >> Seems like <startup> might also be an interesting place to target
> >> actions, but I can't think of a good example.
> >>
> >> There are always scenarios where something is useful, and the problem
> >> with ruling it out is that it becomes needed at some later point.
> >> We've a habit of ruling out things and later wishing we had them.
> >>
> >> Is the easy fix to just put a datastore leaf under rpc/action and
> >> have it default to operational?  Any specific RPC can define its
> >> own datastore leaf of hard-code the database in the description
> >> (explicitly or implicitly <operational>), but the <action> RPC only
> >> gets this if we make a new parameter for it.
> >>
> >> Thanks,
> >>  Phil
> >>
> >
> >--001a11411b0ad2d58d055cee96cb
> >Content-Type: text/html; charset="UTF-8"
> >Content-Transfer-Encoding: quoted-printable
> >
> ><div dir=3D"ltr">Hi,<div><br></div><div>So a server will be required to
> gue=
> >ss the correct datastore until it</div><div>finds the right one that
> matche=
> >s the action instance?</div><div><br></div><div>=C2=A0
> =C2=A0&lt;action&gt;=
> ></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;top&gt;</div><div>=C2=A0
> =C2=A0 =
> >=C2=A0 =C2=A0 =C2=A0 &lt;list1&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
> >=C2=A0 =C2=A0 =C2=A0&lt;key&gt;10&lt;/key&gt;</div><div>=C2=A0 =C2=A0
> =C2=
> >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;do-test&gt;</div><div>=C2=A0 =C2=A0
> =C2=
> >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;datastore&gt;candidate&lt;
> /datas=
> >tore&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> =C2=A0&lt;/do-=
> >test&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> &lt;/list1&gt;</div><=
> >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;/top&gt;</div><div>=C2=A0 =C2=A0
> &lt;/a=
> >ction&gt;</div><div><br></div><div>The server will guess the datastore
> in s=
> >ome proprietary order and parse</div><div>instances of /top/ and
> /top/list1=
> >.=C2=A0 Then it finds the &lt;do-test&gt; action</div><div>and parses the
> i=
> >nput to get to the datastore and find out the real datastore</div><div>to
> u=
> >se.=C2=A0 If the server guessed wrong, then it reparses the
> &lt;action&gt; =
> >against</div><div>the requested datastore.=C2=A0 Hopefully the schema
> trees=
> > match up.</div><div><br></div><div>Will vendors do all the extra work
> requ=
> >ired to support this sort of thing?</div><div>I doubt
> it.</div><div><br></d=
> >iv><div><br></div><div>Andy</div><div><br></div><div><br></
> div><div><br></d=
> >iv><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue,
> O=
> >ct 31, 2017 at 11:36 PM, Phil Shafer <span dir=3D"ltr">&lt;<a
> href=3D"mailt=
> >o:[e-mail]" target=3D"_blank">[e-mail]</a>&gt;</span>
> wrote=
> >:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
> .8ex;border-le=
> >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:<br>
> >&gt;ii) However, as far as I can see, it doesn&#39;t make sense for an
> acti=
> >on to<br>
> >&gt;directly affect the contents of any configuration datastore, that
> shoul=
> >d<br>
> >&gt;be done via a purpose built rpc (like edit-config).<br>
> ><br>
> >An example action would be to retrieve the=C2=A0 fingerprint of an ssh<br>
> >key.=C2=A0 I might want to get the fingerprint of a key in
> &lt;candidate&gt=
> >;<br>
> >before I commit it.<br>
> ><br>
> >Or I could have an action that sets the SNMPv3 auth key to a random<br>
> >value, and I want to invoke that action against &lt;candidate&gt;.<br>
> ><br>
> >Seems like &lt;startup&gt; might also be an interesting place to
> target<br>
> >actions, but I can&#39;t think of a good example.<br>
> ><br>
> >There are always scenarios where something is useful, and the problem<br>
> >with ruling it out is that it becomes needed at some later point.<br>
> >We&#39;ve a habit of ruling out things and later wishing we had them.<br>
> ><br>
> >Is the easy fix to just put a datastore leaf under rpc/action and<br>
> >have it default to operational?=C2=A0 Any specific RPC can define its<br>
> >own datastore leaf of hard-code the database in the description<br>
> >(explicitly or implicitly &lt;operational&gt;), but the &lt;action&gt;
> RPC =
> >only<br>
> >gets this if we make a new parameter for it.<br>
> ><br>
> >Thanks,<br>
> >=C2=A0Phil<br>
> ></blockquote></div><br></div></div></div>
> >
> >--001a11411b0ad2d58d055cee96cb--
>