On Fri, Nov 6, 2015 at 7:20 PM, Russ White <[email protected]> wrote: > > It does. One other point that Jason Coleman, Jason Sterne and I were > > discussing yesterday is how we handle config in this same pane of glass > > model. That is, if I want to override a route via config, how would > > that work with existing ephemeral state? > > > > The idea proposed was to be able to assign a priority to those [static] > > routes that would, in essence, make them ephemeral with the associated > > priority. This would allow one from the CLI participate in the I2RS > > process. > > Static routes are always the monster under the bed for this sort of > stuff... > The main problem (it seems to me) is how they've been implemented over the > years -- I don't know enough about every implementation to know if treating > them as "just another process" would be painful. Here's where some folks > currently maintaining actual code stepping in and saying, "this would be > really painful," or, "this wouldn't be a problem," would be really helpful. > If it's going to be painful, then we might need some way to indicate which > clients can do what. >
The RESTCONF server has its own internal mechanisms to deal with the interface between the protocol and the internal instrumentation. To some degree, this hides ordering details, etc. from the client. > I think the main problem with this entire way of looking at things is > Joel's > point on complexity, particularly in the agent. It would also be helpful to > try and nail what that complexity looks like, and if there is any way to > reduce it, such as -- > > Would treating a complete set of "things" as a single "object" that cannot > be broken apart be helpful? What do those sets of things look like? > > This is exactly the sort of thing that the YANG model needs to tell the server in machine-readable terms. Implementation of stop-on-error and continue-on-error is actually harder than it seems. We never leave invalid data in the running datastore. Pruning the error data and just accepting the good data is mostly arbitrary, wrt/ pruning the least amount of the ancestor subtree. Pruning data can cause a ripple effect wrt/ other validation rules, such as must/mandatory/min-elements. Knowing what constitutes a complete set of a "thing" is not in scope in YANG. IMO, YANG Packages could solve this problem. ;-) Would limiting this sort of capability to a small number of objects in the > model be helpful in some way? IE, this doesn't seem useful to me for links, > but it does for routes. Can we figure out what the use cases are, and try > to > limit the number of objects for which such a capability is to a minimal > number? > Yes -- this is the purpose of the "ephemeral true | false" statement that we want to add to YANG. It could be added to a data model (either directly or from another module somehow) to indicate what an I2RS server is expected to support. > Would it be helpful to combine these two concepts? IE, only objects that > can > be treated as a "single atomic thing" can have a backup? Is it useful to > tie > these concepts together to limit the scope of adding more than one plane to > the object? > > What if the nature of "single atomic thing" is use-case specific or even operator preference specific? As soon as you have 2 use-cases that can share the same data, the possibility of an edit-collision from normal operation exists. It also may not really be safe to have the ephemeral client take over entire sub-trees (e.g. replace instead of merge). There could be new nodes or augmentations unknown to the ephemeral client that may not need to be disabled. I don't know the answers here, just trying to find a middle path that works, > and doesn't introduce too much complexity in return. > :-) > > Russ > > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
