On Wed, Mar 04, 2015 at 03:57:50PM -0800, Andy Bierman wrote: > On Wed, Mar 4, 2015 at 3:09 PM, Juergen Schoenwaelder > <[email protected]> wrote: > > On Wed, Mar 04, 2015 at 02:42:44PM -0500, Jeffrey Haas wrote: > >> > >> There is a presumption that it may be possible for the I2RS agent to > >> restart. Given that a number of I2RS operations are likely to be built > >> using multiple interactions with the agent, it's necessary to understand > >> what state the agent may be in with regard to last-reset. A simple but > >> unscalable way to implement this is to preceed each operation with a > >> get/get-config to verify the state of the system prior to sending in the > >> next I2RS operation. > >> > > > > If this is a problem (which I am not sure), then send a get/get-config > > before each edit operation won't buy you much since the agent can > > still restart inbetween. > > > >> What is likely more stable is simply knowing whether > >> the system is in the same state as when you last interacted with it. > >> > >> A version numbering system of some sort, whether system-wide or potentially > >> as part of some models (perhaps even just I2RS models) would be sufficient > >> to provide such a checkpoint. > >> > >> An example of the problem space this would address presuming three > >> operations must be completed to accomplish a given I2RS goal, "A B C". > >> If the agent crashes after B has been done, C may either complete with no > >> errors, or may fail before the setup state for A and B are no longer in the > >> system. > > > > The simple solution is to make "A B C" one atomic edit. > > > > > We use entity tags and If-Match in RESTCONF so the client can > be sure it is editing the correct version of the resource instance. > This works nicely for persistent configuration, especially if > the server can reboot with the same config ETags. > > If-Match will cause the edit to fail if the server reboots and the > I2RS state is gone. > The client will get a 412 Precondition Failed response and know it might have > to > start over. > > RESTCONF only requires the server to maintain an ETag for the config root. > Finer granularity (e.g., the parent resource has an ETag) is probably needed > to support multiple concurrent edits. >
Thanks, this all makes sense. So there is a viable mechanism to create a sequence of linked edits. The main trade-off, however, between a single atomic edit and a sequence of linked edits is who is taking the pain to cleanup the mess if things fail in the middle. If you write a client, you love the server to do it. If you write a server, you love the client to do it. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
