I think that there may be a better way here: The data modelers design the
model on the assumption that an operational state datastore will be present.
We can then use a pyang plugin to generate an extra YANG model that contains
the missing state leaves that would be required for the split config/state
trees. E.g. if it finds a config leaf in foo/speed it creates a module that
contains foo-state/speed. I've been playing around with pyang and I don't
think that this would be too hard to do.
I generally support this approach as stop-gap solution while the industry goes
thru the transition. However, I recommend a variant whereby the pyang plugin
only migrates the config false values (not also the config true values). The
reason for this is as follows:
Migrating only the config false values is sufficient for matching existing
functionality (read: a must-have requirement); that is, currently top-level
/foo-state is used to support conveying the opstate for system-generated
objects, that have lifetimes independent of config.
Migrating the config true nodes also is possible, but only needed if wanting to
report the opstate value for config true nodes (e.g., hostname), but this would
be above and beyond what is possible today (read: a nice-to-have requirement),
and hence I’d rather steer folks towards the new approach rather than
double-down on the approach we’re trying to get away from.
> This is a real hack.
>
> I liked the if-feature approach much better
> e.g.
>
> leaf oper-speed {
> if-feature "not operational-datastore";
> ...
> }
Is your proposal for the YANG modules to simultaneously define both
opstate-aware and opstate-unaware trees? Wouldn’t that make the modules less
readable, largely redundant, and ripe for inconsistencies?
Kent // as a contributor
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
