On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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. 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. Well, if you understand the edits,... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
