Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

From: Randy Presuhn <[email-masked]>
Date: Tue, 6 Oct 2015 11:04:21 -0700 (GMT-07:00)

Hi -

> From: Andy Bierman
> Sent: Oct 6, 2015 10:01 AM
> To: Juergen Schoenwaelder , Robert Wilton , Kent Watsen , "[email-masked]"
> Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
...
> > And I would not be surprised if we also need this sooner or later:
> >
> >  Mixed configuration server - a configuration server that processes
> >  some configuration operations as synchronous configuration
> >  operations and some configuration operations as asynchronous
> >  configuration operations.
>
> As I already commented, this is how servers works today.
> The data model details, server design, sub-system design,
> ASIC design, etc.can all factor into whether or not the
> config is applied when <ok/> is returned for the edit or
> commit.

Agreed.  Realistically, the semantic of <ok/> is merely
that the data has passed whatever checks the server applies
and has been successfully committed to the appropriate
data store.  (If the system is built around a model of
eventual consistency, even that might be a bit dicey.)
It's risky to assume anything more than that in situations
involving anything like subagent / extensibility
technologies, and positively foolhardy if proxy or
translation middleware is in the picture.

> It is also unwise to assume that the server can determine
> the applied state for every possible leaf.

Yes, but even when it *can*, is it worth modeling?

I think this discussion needs to be grounded in
what is operationally significant.  For example, in one
system I'm familiar with a configuration change would be
validated, committed to storage, the hardware reconfiguration
sequence queued for execution, and acknowledged.  The hardware
reconfiguration involved reprogramming FPGAs, so there'd
be a race condition between acknowledgement of the request
and when the hardware would actually start doing whatever
was requested.  That delay was, at most, milliseconds.

  - Did the server know this was happening?
    Of course.

  - Would it have been possible to expose this "asynchronous"
    state transition via a management interface.
    Sure.

  - Would that be worthwhile to model or implement?
    I don't think so.

Randy