On Fri, Dec 16, 2016 at 10:31:31AM +0100, Martin Bjorklund wrote: > 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.
I still wonder why it could be useful to provision things like the mfg-name or the serial-num. I would rather like to know what is really there instead of overwriting these 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. > > 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. This may make sense. > > 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). This way of pre-configuring that name may indeed make sense. Lets see if this is what BBF really wanted. /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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
