Joel, RESTCONF will return 409 (Conflict) if a NETCONF datastore is locked.
Thanks, Kent > On Nov 13, 2014, at 8:21 PM, Joel M. Halpern <[email protected]> wrote: > > Just to finish what I did not mention, remember that I2RS does not lock, and > is expected to ignore any Netconf locks. (I think this is similar how > restconf is expected to work, but I am not sure.) > > Yours, > Joel > >> On 11/13/14, 11:16 PM, Joel M. Halpern wrote: >> The case that causes complications for treating only one store is: >> 1) You have a running box, with a CLI client A and an I2RS client. The >> I2RS client understands and expects that its changes will NOT be committed. >> >> 2) In some order, A and B each make changes in the device. It is >> sufficient for this case that they are completely non-overlapping changes >> >> 3) After both changes have been made, and the box is running happily, >> the CLI client says "commit". >> >> In order to meet the I2RS requirements, the data that the I2RS client >> has provided MUST NOT be saved in persistent store. Things may well >> break if it is stored. >> >> Yours, >> Joel >> >>> On 11/13/14, 11:08 PM, Fedyk, Don wrote: >>> Hi >>> >>> I've been trying to understand the models here. To me what we are >>> describing is a general case of 2 entities trying to configure a switch. >>> >>> Consider one operator or user for short. >>> A user may be able to write to the running config datastore some subset. >>> A user may copy that to the config datastore (save config). (If they >>> do not the copy the running subset is ephemeral) >>> Also: >>> A user may write to a candidate config datastore some subset. >>> A user may verify/activate the candidate config. >>> A user may commit that candidate config (once running) (save config). >>> (If they do not commit that config subset is ephemeral). >>> Some devices do not support all config operations. >>> >>> Then consider two users trying both to config the same device. >>> A user may be blocked from changing config items that are currently >>> ephemeral. >>> A user may be allowed to override the config items that are ephemeral. >>> The override may be priority based where user A with higher priority >>> can override user B but not the reverse. >>> >>> So if the user A is i2rs agent and the user B is an operator where the >>> config items may allow priority per item, doesn't this cover the >>> bases for what is needed? >>> >>> Cheers, >>> Don >>> >>>> -----Original Message----- >>>> From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern >>>> Sent: Thursday, November 13, 2014 10:06 PM >>>> To: Joe Clarke; [email protected] >>>> Subject: Re: [i2rs] Point about writable running >>>> >>>> I agree Joe. The challenge with using any of the existing stores is >>>> that if >>>> someone says "commit" they need to get the NetConf / RestConf normal >>>> changes to that, but not the I2RS changes. >>>> >>>> Yours, >>>> Joel >>>> >>>>> On 11/13/14, 9:57 PM, Joe Clarke wrote: >>>>> During today's meeting Dean made a comment that we could use writable >>>>> running as a way to do ephemeral state. I have a concern about this. >>>>> I know it may seem like an implementation detail, but I feel that most >>>>> vendors (and operators) assume that things in the running datastore >>>>> _could_ become persistent. >>>>> >>>>> That is, if I write to the running data store, and my human user sees >>>>> these I2RS ephemeral state in the "show running-config" (or the like), >>>>> they might think those are persistent. There is no indication that >>>>> they are ephemeral. On top of that, some NMS systems that use >>>>> screen-scraping for config archive might grab this ephemeral config >>>>> and later restore state that should not be restored. >>>>> >>>>> I just wanted to bring this up as I would rather see more of the panes >>>>> of glass approach rather than try to override an existing datastore >>>>> for this kind of thing. Or maybe I misunderstood Dean's comment... >>>>> >>>>> Joe >>>>> >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
