Juergen Schoenwaelder <[email protected]> wrote:
> On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <[email protected]> wrote:
> > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> > > > Hi,
> > > >
> > > > Issue https://github.com/netmod-wg/entity/issues/13
> > > >
> > > > Should the model support pre-configuration of hardware components?
> > > > The current model supports pre-configuration of components provided
> > > > the operator knows the name of the component to be installed. A more
> > > > useful model would use the parent component, class, and
> > > > parent-rel-pos as identification. If the system detects a component
> > > > and there is configuration available for the parent component,
> > > > class, and parent-rel-pos then the system would instatiate the
> > > > component with the provided name, and optionally additional
> > > > parameters.
> > > >
> > > > See also various mails from Timothy Carey and Bart Bogaert on this
> > > > issue.
> > > >
> > > > Personally, I think that we should add these nodes, since the ML
> > > > comments indicated that pre configuration is pretty useful.
> > > >
> > >
> > > I am still not sure what exactly this will do. I have been looking at
> > > <https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html>.
> > > I am provisioning mfg-name (Preferred value is the manufacturer name
> > > string actually printed on the component itself (if present).) but all
> > > I have is that something of a certain expected class has been plugged
> > > into a certain position of the parent container. Also note that
> > > mfg-name scopes comparisons of other properties. I would have similar
> > > questions concerning the model-name; how can a provisioning system
> > > predict the 'vendor-specific model name identifier'? Or is the whole
> > > idea that if I plug something that does not match, the component is
> > > left in a special state (which one)? If this is the intention, then
> > > this needs to be spelled out clearly somewhere.
> >
> > The current model works fine if the user looks into the state list and
> > finds a component that he wants to configure. To do this, he uses the
> > name of the component as found in the state list, and writes the
> > config for this component.
> >
> > The current model also supports pre-configuration if the user somehow
> > can predict the name of a component to-be-inserted. In this case he
> > can write the config, and when the component is plugged in, the system
> > will derive the component name, and check the config list for this
> > name. This is a fragile model.
> >
> > In the proposed model, the user can provide configuration for a tuple
> > (parent, class, parent-rel-pos). If the server finds a component in
> > the state list (or such a component is later plugged in), then the
> > corresponding config leafs are used for the state of this component
> > (including the name).
> >
> > If you plug in something that doesn't match the config list, well that
> > just means that nothing has been configured for this component, and
> > the system will populate the state list accordingly.
> >
>
> Well, this is not what I read out of
>
> https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
>
> since there are leafs like mfg-name and model-name that seem to be
> hardware component properties.
The description statements in this email are just copied from the
corresponding config false nodes. I think they need to be rewritten;
compare with serial-num. This text can probably be further improved.
The idea is that the user probably would configure say mfg-name only
if the system cannot detect it automatically.
> And the config list is still indexed by
> a name; so for list elements that have a (class, parent, position)
> triple, the name would be arbitrary and not necessarily matching the
> component name.
I think that the idea is that if there is a matching triple, then the
system MUST use the configured 'name' as the 'name' also in the state
list. One reason for pre-confiugring these components is to be able
to refer to them in other config.
> Well, if you understand the edits,...
I think the idea would be explained along these lines:
The sytem conceptually behaves like this:
1. When a physical component is detected, the system will initialize
an entry in the /hardware-state/component list.
If there is an entry in /hardare/component list with a matching
(class,parent,parent-rel-pos) triple, then the state entry is
initialized with the configured values for all configured leafs
(name, mfg-name, ...).
If there is no such matching entry, the system assigns a 'name'
in an implementation-specific manner.
If there is an entry in /hardare/component list with a matching
'name' and where the triple (class,parent,parent-rel-pos) is not
set, then the state entry is initialized with the configured
values for all configured leafs (name, mfg-name, ...).
Otherwise, the state entry is initialized with the detected values
for all leafs.
2. If the /hardware/component list is modified (i.e., someone changed
the config), then the system MUST behave as if it was restarted
and followed the procedure in (1).
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
