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
