Re: [netmod] OpsState and Schema-Mount

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
> 
> In particular, I think that the guideline would be along the lines:
> If a given module "foo" only contains state and no configuration, then
> having a single top-level "foo" config false node is fine, but if a given
> module contains both config and state then the recommendation is to put that
> under a config=true "foo" top-level node.  Refining that slightly, If the
> state data is relevant even if "foo" hasn't been enabled then make the top
> level "foo" an NP container.  If "foo" has to be enabled on the system for
> the state data to be relevant then make "foo" a P container (or give it a
> separate foo/enable leaf).  In summary, I would suggest that the foo state
> data should be pushed as far down the combined config/state tree as
> possible.  It should be sited below (or adjacent to) whichever config node
> is required to make that state data relevant.
> 
> If config and state are in the same tree then it is easy to return all the
> data in one RPC, or have separate RPC operations that just return
> configuration (e.g. <get-config>), or just return "state + containing
> hieararchy" (e.g. a newly defined <get-state>, or equivalent).
> 
> Having separate foo vs foo-state trees at the top level is always going to
> make it harder to return and manage a combined view of the config and state
> data.

I think it is crucial to separate (a) what protocols do today and (b)
what protocols might do at some time in the future.

The current protocol reality, that is (a), paired with the reality of
network interfaces has lead to the (/interfaces, /interfaces-state)
design pattern and until we have (b) in place I do not think we have
really an alternative for the (/interfaces, /interfaces-state)
design pattern.

If you have config and state are in the same tree, you simply can't
represent certain things that exist in reality. A single tree may look
'simpler' but in several cases also simply 'unusable'. We did not
particularly like the (/interfaces, /interfaces-state) design but it
was the only solution that seemed to work for all cases given the
protocol reality we were in.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>