Re: [netmod] explicit mount

[Robert Wilton <[e-mail]>]

On 25/02/2016 11:16, Martin Bjorklund wrote:
> Robert Wilton <[e-mail]> wrote:
>> Hi Martin,
>>
>> On 25/02/2016 09:31, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder <[e-mail]> wrote:
>>>> On Thu, Feb 25, 2016 at 10:14:05AM +0100, Martin Bjorklund wrote:
>>>>> Juergen Schoenwaelder <[e-mail]> wrote:
>>>>>> On Thu, Feb 25, 2016 at 09:43:34AM +0100, 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).
>>>>>> OK. I understand now that the whole set of modules on a mount point
>>>>>> form one chroot environment. This was not clear to me yet but of
>>>>>> course makes a lot of sense. So a static schema mount would have to
>>>>>> define a set of modules and not just a single module to lead to the
>>>>>> same chrooted behavior.
>>>>> Yes, but then you can't use it to define your own beautiful
>>>>> structure.
>>>> I am not sure yet why this is the case.
>>> Each such mount point is chrooted.  This implies that if you want to
>>> put module A in some place, and B has a reference to A, A and B must
>>> be mounted together.  Thus I cannot put them anywhere to form a
>>> beautiful hierarchy.
>> As long as B is mounted in the same datastore as A then is it possible
>> that B could moved to be mounted on some other path?
> Yes, but then you'd need some special syntax to say that they are
> related.
Wouldn't any path references be sufficient to indicate whether the 
modules are related?

>
>> References to/from B would need to be fixed up, or are you saying that
>> fixing the references is intractable?
> I think it would be extremely complicated, both on the server and on
> the client side.
This probably feels similar (but actually simpler) than mapping between 
different sets of modules.  E.g. mapping from OpenConfig modules to IETF 
modules, or from OpenConfig/IETF modules to a native device schema.

I doubt whether this idea will be particularly well received, but:

Would it be possible to programmatically generate a new set of YANG 
module definitions from the originals with updated paths/references.  
I.e. both sets of module definitions model exactly the same data, just 
the location of that data is in different places.  A client could then 
solely interact with the new set of YANG modules if they wished.  A 
function can be programmatically generated and used to map between the 
two equivalent models with different node paths.  I would imagine that 
this mapping could be done either on the client side or server side.

Even if this approach is valid, it would appear to only really solve the 
"can't use it to define your own beautiful structure.", and I'm not sure 
whether that's an actual requirement here.

Rob


>
>
> /martin
> .
>