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
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
