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. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
