hi Seb

Sebastien Roy wrote:
>
> At the very least, the service instances hold properties for those 
> objects.  The semantics behind instance states certainly needs to be 
> defined.  If NWAM is not managing data-links, as an administrator, I 
> might be satisfied with the services representing what is configured, and 
> using the tools I've always used to observe the underlying objects' state 
> (i.e., dladm show-link).
>
>   
i definitely agree that data-link properties should be stored in
SMF, and that the storage location should be invariant whether
NWAM is running or not, but i guess what i'm not getting is the
advantages to having a SMF instance representation in the
non-NWAM case.

i recall when Dan was looking at the SMF representation for
the UV work initially, i suggested using property groups under the
network/datalink-management instance to store link information.
i prefer this solution for a number of reasons, primarily because
it exposes no additional SMF instance interface. i fear that
having SMF representations of links visible in the "svcs" output
represents another administrative interface in the "NWAM disabled"
case, and given that we're ultimately aiming for "NWAM on by
default" (where admins will hopefully rarely need to interact with
services),  i think this is preferable. in the current design, if NWAM
has not been run, there are no instances present under network/auto,
and if it has run, but has been administratively disabled, the
created instances will be offline, and "svcs -x" will report
that they are offline because nwam is offline (similarly to how
inetd services work).

>> the intent of the use of the "auto" namespace in the current design was to
>> underline the fact that the instances relate to "NWAM mode" only, so if 
>> that's
>> not the case, i agree that the "auto" prefix is misleading.
>>     
>
> My personal opinion is that the object "data-link" or "IP interface" 
> exists and is manageable regardless of whether a human or a computer is 
> doing the managing.  Having different FMRIs to represent who's managing 
> them seems strange, as their properties are the same regardless.
>
>   
right, i guess i should have clarified that my proposal wasn't
to have an alternate instance for a link in SMF when NWAM
is not running - it was rather to have no link instance FMRI
representation at all when NWAM isn't running. the current link
properties would be stored in the same location regardless of
whether NWAM's running or not (under
network/datalink-management).

>>>   Or is it simply that NWAM will always be enabled in Phase I?
>>>
>>>       
>> it won't, which makes me think this needs a lot more work in light of the
>> consideration you've mentioned above. thanks again!
>>     
>
> That's part of the reason why Max was brought in to help.  Bridging the 
> gap between /etc/dladm/* and SMF is not obvious.
>
>   
agreed :-(

alan

Reply via email to