On Thu, Nov 13, 2014 at 6:57 PM, Joe Clarke <[email protected]> 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 think the local-config=persistent assumption is flawed. In IOS, local config does not persist unless and until the "write mem" command is invoked. Persistence is often an operator decision, not hard-wired into the transaction. > 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... I agree. Tagging the config data as ephemeral does not work if the local config needs to re-activate once the I2RS state is removed. (e.g., next-hop example). A YANG instance-identifier cannot distinguish between the config and ephemeral versions of each node. I think Dean meant the I2RS edits take effect right away, like :writable-running in NETCONF. There is no commit phase, like with the candidate datastore. > > Joe Andy > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
