-----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
