Re: [netmod] revised-datastores and commonality of schemas

[Robert Wilton <[e-mail]>]

I agree.

I think that a configuration template is just another form of 
configuration, and hence would expect that the template itself appear in 
candidate, startup, running, intended, operational.

There could also be "system templates" that are not directly 
configurable, and do not appear in configuration (e.g. I think that a 
system defined Loopback0 interface could be thought to be part of a 
"system template").  E.g. basically just configuration that the system 
always merges in from running to intended.  Today, I would not expect to 
"see" these system templates, only the affect of them in <intended> and 
<operational>.

Thanks,
Rob


On 02/11/2017 21:31, Phil Shafer wrote:
> "Sterne, Jason (Nokia - CA/Ottawa)" writes:
>> The <running> DS needs to have both the template itself in the schema as well as
>> whatever nodes are used to hold 'exploded' data.  But what about intended and
>> operational ?
> For JUNOS, we carry both the raw and expanded views, though nothing
> in JUNOS is looking at the raw data outside of the UI code.  But we
> carry it, so that scripts can access this information and find the
> original "intent" for config.
>
> For example, if my interface template looked like:
>
> interfaces {
>      apply-macro so-0/0/0 {
>          inet-address 10.3.2.1/30;
>          role customer-facing;
>      }
> }
>
> and then my commit script turned this into traditional JUNOS
> config, like:
>
> interfaces {
>      so-0/0/0 {
>          unit 0 {
>              family inet {
>                  address 10.3.2.1/30;
>                  filter customer-facing;
>               }
>               family mpls;
>               family iso;
>          }
>      }
> }
> protocols {
>      bgp {
>          group customer-facing {
>              peer 10.3.2.2 {
>                  local-address 10.3.2.1;
>                  policy customer-facing;
> ...
>
> And whatever else "customer-facing" means.
>
> Both sets of config will be in <intended> and <operational> so that
> when I find an interface that's down, I can look (in <operational>)
> at the original apply-macro and see the role of the interface to know
> how loud an alarm I should be raising.
>
> Thanks,
>   Phil
> .
>