Renee Danson wrote: > On Fri, Nov 02, 2007 at 02:48:47PM -0400, Sebastien Roy wrote: >> 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.
Yes! I think this makes a ton of sense. For data-link services, the configuration is reflected in each service's properties. This would, however, be a bit muddled for IP interface services, as their configuration would be split between contents of /etc/hostname.* (and /etc/dhcp.*) files when NWAM is not enabled, and service properties when NWAM is enabled. That is, of course, unless you decide to do away with /etc/hostname.* files entirely. :-) > 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? Would it help if what is dlmgmtd today in Clearview UV and this restarter daemon were the same thing? -Seb
