What is the alternative? Lock out operators from committing a running datastore when anything is I2RS ephemeral? Is there an I2RS withdraw ephemeral? How would a user invoke that?
I think I2rs could also accidentally commit any users ephemeral config too without a mechanism to prevent it. It works both ways. Cheers, Don > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern > Sent: Thursday, November 13, 2014 11:28 PM > To: Fedyk, Don; Joe Clarke; [email protected] > Subject: Re: [i2rs] Point about writable running > > I don't recall seeing that form of commit in any protocol that has been > proposed. I think it would be rather hard to do. > > Yours, > Joel > > On 11/13/14, 11:22 PM, Fedyk, Don wrote: > > 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
