I believe that shortening tranistion pain is in the longer term better than prociding tools that at the end just extend the transition pain.
/js On Tue, Jan 10, 2017 at 07:08:47PM +0000, Kent Watsen wrote: > 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 > > > _______________________________________________ > Netconf mailing list > netc...@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod