Then the commit from A would have to be "commit what A wrote to running store" not "commit the running store". No?
Don > -----Original Message----- > From: Joel M. Halpern [mailto:[email protected]] > Sent: Thursday, November 13, 2014 11:17 PM > To: Fedyk, Don; Joe Clarke; [email protected] > Subject: Re: [i2rs] Point about writable running > > 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
