Andy writes: > I am wondering why operators would want to compare 2 massive subtrees > in the first place, where 1 is static and the other is changing constantly. > > Do they really want this complex task or do they just want to > determine if the intended config has been applied yet?
I think that it is more the latter. And there have been suggestions for solutions to provide something like a yang-patch to describe just the diffs. Makes sense to me! K. From: Andy Bierman <[email protected]<mailto:[email protected]>> Date: Wednesday, October 14, 2015 at 2:56 PM To: Kent Watsen <[email protected]<mailto:[email protected]>> Cc: Robert Wilton <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration" On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <[email protected]<mailto:[email protected]>> wrote: Thank you Robert for bringing the discussion back to the github issues. Robert writes: > In particular: > - does it include support for templating (as per > openconfig-netmod-opstate-01 section 7.3.)? > - is it allowed to represent system created objects that have no > corresponding configuration? > > Requirement 1.D states D. For asynchronous systems, when fully synchronized, the data in the applied configuration is the same as the data in the intended configuration. > > So, if this requirement statement stands as being valid (which I think it > should) then that would imply that the answer for both the two issues above > must be "no". The only question would be whether these need to be explicitly > listed out? [KENT] so I think I have to (begrudgingly) agree with your logic. I have heard the operators state that they want the intended/applied comparison to be drop-dead simple. To that end, it would not be possible to flatten templates or apply defaults, or make any other change - it needs to be as close as possible to a carbon-copy of the original intended configuration (where deviations are allowed only for cases like a missing line-card). To this end, yes, I think that we could tack on a statement like the following: That is, the intended configuration is a subset of the applied configuration where omissions are only due to when the configuration cannot be applied (e.g., a missing line-card). What do you think? I am wondering why operators would want to compare 2 massive subtrees in the first place, where 1 is static and the other is changing constantly. Do they really want this complex task or do they just want to determine if the intended config has been applied yet? Andy >> - how does it relate to the state of the system after a equivalent >> synchronous config commit (if at all)? >> > Again, I think that definition of requirement 1.D, along with the proposed > definition of synchronous configuration operation vs asynchronous > configuration operation, will provide a sufficient answer to this question. > I.e. that the state of the system after an asynchronous config operation > must, when fully synchronized, be the same as the state of the system after > an equivalent synchronous configuration operation completes and replies back. [KENT] I agree with this, but I think it impacts issue #6 more so than issue #4 - right? Thanks, Kent _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
