Nicolas Droux wrote On 09/21/06 12:42,:
> >> 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 you would need the config file if there was a legacy of its usage prior to the introduction of SMF. sharemgr (PSARC/2005/374 Share management improvements (*) ) is a precedent of how to approach the migration away from using /etc/dfs/dfstab towards an SMF managed persistent repository of configuration. Ideally of course, make the right choice upfront, and not deploy a legacy that we (and Sun customers) have to migrate from in the near future. > 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. > Kais (*) Reference to info incaccessible to non Sun addressees yet. the ARC case above was announced on opensolaris.org/os/community/arc however the content isn't yet in the public mirror of the ARC docs. >