Hi Alan, Alan Maguire wrote: > Sebastien Roy wrote: >> I'm unclear about the implications of data-link instances being under >> the "auto" namespace. From past discussions we've had between the >> Clearview, NWAM, and SMF teams, I was under the impression that there >> was consensus that data-link interfaces should be represented as SMF >> instances regardless of whether NWAM is enabled. Is that not the case? > > thanks for raising this issue! i'm afraid i wasn't aware of this > requirement. > would it be possible to reconstruct some of the details of these > discussions here?
The gist of the consensus was that network data-link interfaces should be represented as SMF service instances on Solaris. Whether those services are managed by a human being typing in dladm commands or by a smart android like nwamd is a separate issue. The contents of the configuration currently contained in /etc/dladm/datalink.conf (in the clearview-uv gate) or /etc/dladm/aggregation.conf and /etc/dladm/linkprop.conf (in onnv-gate) need to end up as SMF properties of individual data-link SMF service instances. > (i tried to locate more information relevant to this awhile ago, but had > no success > unfortunately). I don't believe minutes of that meeting exist, and I'm not sure who sent out a summary. I believe a number of people on these mailing lists were in attendance and can correct me if my understanding is inaccurate. > what i'm interested in specifically is this - in the > "NWAM disabled" > case, is it the case that the SMF representation of datalinks is > intended to be simply > a repository of datalink configuration information, or are the datalink > instance states > also intended to reflect link state? (e.g. a wireless datalink might be > "online" if > connected to a WLAN). if the instances are to be used in the non-NWAM case, > as an administrator, i'd expect some sort of coordination between link > state and SMF instance state i think. 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). > 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. >> 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. -Seb
