On Fri, Nov 02, 2007 at 02:48:47PM -0400, Sebastien Roy wrote: > Hi Alan, > > 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.
No, minutes don't exist and I don't think any summary was sent out. I've tried to start piecing together some of the discussion and will be sending out mail about that shortly! > I believe a number of people on these mailing lists were > in attendance and can correct me if my understanding is inaccurate. FWIW, I was there, and I agree with your summaries here. > > 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). Agreed. > > 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. Also agreed. So the question is how does the management happen when the nwam daemon is not doing it? I'm wondering if we might be able to solve this problem by taking a somewhat larger step in nwam phase 1 than we'd planned. Currently, the network/physical:default start method is a script that examines the /etc/hostname.* and /etc/dhcp.* files and brings up the interfaces represented by those files. Alternatively, that service can be disabled and network/physical:nwam can be enabled instead; in which case nwamd is started, which brings up/down interfaces dynamically depending on network conditions. The ultimate goal was to have nwam enabled all the time, and to eliminate network/physical:default. But given the desire to get some functionality in sooner, phase 1 was split off to support more common configurations; phase 2 will come later with more complete support. Since phase 1 will not support all network configurations (no vlans, aggregations, ipmp groups), though, we didn't think we could eliminate network/physical:default at this point; there still needs to be an option for those systems that required more complex configurations. So if we're moving all the configuration data into the instances, to be accessed by nwamd as well as the manual tools such as dladm, can we also move the start-up bits as well? Would it be possible to go ahead and eliminate network/physical:default now, and have start methods associated with the link and interface instances (based on the relevant bits of the existing network/physical:default start method) that can be used for the non-nwam case? That way, the administrator decides which of the interfaces should be configured by enabling/disabling the appropriate service instances. I think this helps non-nwam systems, as changes to the configuration can be more easily accomplished with svcadm commands rather than reboots. The delegated restarter would still be a problem: we would want the restarter to be nwamd if the nwam service were enabled, but that wouldn't make sense if the nwam service were disabled. Does it make sense to try to extract the restarter bits from nwamd and have a separate net-mgmt daemon? -renee
