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.

>

Reply via email to