On Sep 21, 2006, at 1:41 AM, Cathy Zhou wrote: > Nicolas Droux wrote: >> Cathy, >> Regarding /etc/datalink.conf (page 58 of your design document): is >> there a particular reason why you haven't adopted SMF to associate >> data-links with their properties? [1] It seems that there is an >> opportunity to model each data-link as instances of a new >> (transient) data-link service. Each data-link instance could then >> be associated with a set of properties, accessed and managed >> through libscf(3LIB), svcprop(1M), visual panels, etc. > While I understand where your request comes from, I don't think > make dladm configuration SMF aware is necessarily part of the > vanity naming project. There are other parts of dladm > configurations (like the aggregation configuration, wireless > configuration) come before the vanity naming work.
So all of this is being unified now under the newly proposed datalink.conf, right? It seems that there is an opportunity to use SMF as part of introducing this unified data-link properties repository. Are you expecting that this file will be used for new classes of data-links coming down the road as well? > But agree it's certainly doable and it is nice to have it > especially because SMF seems to be the right direction to go. > Before we commit to do SMF, we'd like to understand better about > your request. We think that whether the link configuration is SMF > aware or it is stored in a /etc configuration file is purely > implementation detail, and it doesn't affect the administrative > model and it is not anything exposed to the customer. Do you agree > on this? Or are you thinking of something more, like making it a > part of SMF service model, that "link" can be a service that > administrative can use the SMF to manage its property? All of the above :-) There's of course the implementation aspect, where SMF can help manage these properties. I.e. does it make sense to provide a new configuration file and management library to capture the properties of data-links, when SMF already provides similar capabilities through libscf(3LIB). Other tools such as ksslcfg(1M) are already using SMF for this purpose. But the value that this can bring to the rest of Solaris architecture in the longer term is appealing as well. Clearview is providing a unified model, the "data-link" which represent the network interfaces on a system. Yet, it is currently disjoint from SMF, which is used to manage the majority of the Solaris services, and is being used as the basis for future management tools as well (e.g. visual panels). I think that by providing SMF integration, we could more fully realize the potential of the data-link model. This could enable, for example: - Integration with the "bottom" of the NWAM service model by allowing datalink instances state to be reflected through service instance state or property change. - Managing properties and states of the data-links through common interfaces (libscf(3LIB), svcprop, visual panels, etc) - Enabling the future integration of data-links with FMA for increased diagnosability ... and more. > If it is the latter, we really think it needs more thought and it > falls out of the scope of Clearview. Clearview is clearly focusing on the usability aspects of network interface management, and SMF is a big part of the management story of Solaris, so I was hoping to see the view of the Clearview team on how they see this evolving in the long term. Nicolas.
