Re: [netmod] explicit mount

[Robert Wilton <[e-mail]>]

On 25/02/2016 08:43, Martin Bjorklund wrote:
> Juergen Schoenwaelder <[e-mail]> wrote:
>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote:
>>
>>>> I think the use cases are rather obvious. I build a device and I like
>>>> to rearrange existing models into a beautiful hierarchy (for some
>>>> definition of beauty).
>>> This would be pretty complicated.  Suppose I define my own beautiful
>>> structure like this:
>>>
>>>    container my-interfaces {
>>>      x:mount-point "if" {
>>>        x:mount-module "ietf-interfaces";
>>>      }
>>>    }
>>>    container my-routing {
>>>      x:mount-point "rtr" {
>>>        x:mount-module "ietf-routing";
>>>      }
>>>    }
>>>
>>> Note that with the mount-point defined in my draft, each mount-point
>>> becomes itw own "jailed" or "chrooted" tree.  So references cannot
>>> cross mount points.
>> Could be the same here.
>>   
>>> In this case, we have references between ietf-routing and
>>> ietf-interfaces.  How would they work?
>> How do they work in your solution? If interfaces is jailed and routing
>> is jailed, how does routing refer to the interfaces?
> My solution does not support "name module mount".  It only supports
> mouting of a "complete" set of modules (that are chrooted) - simply
> because this is what we understand, have implemented, and have been
> running for the last ~5 years.  (The same goes for ODL, I believe).
I have been wondering whether "name module mount" is really about 
mounting only specific modules, or actually allowing the mounting schema 
to statically indicate which modules are guaranteed to be present.  I.e. 
specifically it doesn't explicitly prohibit other modules/data nodes 
from potentially also being mounted at the same path, but in the normal 
case you wouldn't expect them to be present.

My reasoning is that you don't want to have to statically specify in the 
mounting schema all augmentations, deviations and features.  But I also 
don't think that the mounting schema can guarantee that the mounted 
schema will always exactly implement the module(s) specified in the 
schema mount and all features without any augmentations or deviations.

So for this to be useful, it means that there has to be a dynamic 
mechanism to determine exactly what modules has been mounted (e.g. like 
the ietf-yang-structural-mount module or ysdl).

Given this, I think that you could possibly end up with just one "schema 
mount" with a couple of options:

The first option would be an explicit list of modules that are 
guaranteed to be mounted at that location (or "*" to indicate a 
"complete" set of modules (that are chrooted).

The second option would indicate where the runtime details of the 
mounted modules can be found: this option might indicate whether details 
of the mounted modules can be found inline in the data tree at the mount 
point using yang-library, or separately in the 
ietf-yang-structural-mount module/ysdl.

Rob