Alan Maguire wrote: > hi Seb > > Sebastien Roy wrote: > >> 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. >> >> >> > ah, got it! > >> 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... >> >> >> >>>> >>>> >>>> >>> 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? >> >> >> > good point - the plan we discussed at the last NWAM meeting was > to try and reconstruct the design decisions from the NWAM/SMF/Clearview > discussion via an email to the relevant -discuss aliases, and work from > there > to ensure everyone's in sync. watch this space... > >>>>>> 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? >> >> >> > from a design perspective, we'd have to figure out > the semantics of administrator enable/disable. > and on the implementation side, i think the key intersection > is the delegated restarter. if we were to use the > same link instances in the NWAM and non-NWAM cases, > we'd need a common SMF delegated restarter external to > NWAM (since NWAM can be disabled) that carries out different > activities based on whether NWAM is enabled or not > (for example for wireless links, in the non-NWAM case > it might try to autoconf the wireless interface, while if > NWAM is running it'll consult the visited WLAN list, > etc.). > This can be done if we can change the SMF instance restarter on the fly. But, it seems to me like a duplicate effort, if we try to implement an external restarter besides nwamd. > the other non-NWAM part of the puzzle would be > ensuring that administrator-driven activities (i.e. dladm > for link instances and ifconfig for IP SMF instances) > lead to state changes to the link or IP interface instances > (if we're representing links in SMF for the non-NWAM > case, i'm assuming that we'd need to represent IP interfaces > too?). i'm probably missing something, but they are > the two major pieces that occur to me offhand. thanks! > Again, to implement IP SMF instances when nwamd is not enabled seems to be another duplicate effort, not only on the implementation, but also on all the related testing work we need to do.
I'm wondering if we can split the functionality of nwamd into two parts - SMF restarter and auto-switching. So, we can always enable restarter part, while make auto-swithing part more flexible (can be disabled/enabled). To some extend, the restarter part is something like the 'external restarter' mentioned by Alan... Max > alan > > _________________________________ > clearview-discuss mailing list > clearview-discuss at opensolaris.org >
