Hi Alan, Alan Maguire wrote: > 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.
Dan actually had implemented all of that as part of Clearview UV (data-link properties in network/datalink-management), at which point Mike Shapiro pointed out that (1) doing this got us no closer to the eventual design than having the configuration data in a flat file, and (2) this was contrary to the philosophy behind SMF services as being administratively meaningful. So we then had this all-day meeting with all three project teams (Clearview, NWAM, and SMF) to figure out how to proceed to make sure that whatever we did with data-link configuration was going to make incremental progress toward the eventual design goal. Regarding (1), at the time, I don't think anyone envisioned having a hybrid design where individual data-link interface properties are not actually stored in the data-link interface service instances as you describe below... > 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). I now better understand your proposal, but I'm afraid of this approach running aground at the SMF atoll. Have you run this idea past Mike Shapiro and the rest of the SMF team? I was under the impression that using network/datalink-management as a convenient means to store configuration information was a non-starter based on our previous (and failed) plan to do so. >>>> 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 :-( So given that Max is tasked with representing data-link interfaces as individual SMF service instances, and that we're told NWAM depends on this work, how does Max's work relate with what you're doing? -Seb
