On Wed, Nov 07, 2007 at 01:01:38PM +0800, Kacheong Poon wrote: > > It seems to me that we should take a step back and look > at the whole project for a moment. The above seems to > suggest that whenever the nwamd is not running, NWAM is > disabled. But the project itself is more than just the > nwamd. There are other changes in the project which are > fundamental to the network configuration. In this sense, > while certain "automagic" parts can be disabled, NWAM > cannot just be "disabled." I am not trying to play word > games. It just does not make sense to me that whenever > the daemon is not running, we need to hide all the changes > made by this project and revert back to the current way. > Instead of simplifying the network configuration, I see > this as creating more new problems for us to solve.
Agreed; I think this sums up what I was trying to say. Though I would argue that words do matter; I think that nwamd should only run when the nwam service is enabled, and that it should be responsible only for the automagic bits. The more general network management functionality should not be called nwam. I would suggest that at least thinking about things in terms of two separate daemons, would help us to come up with a cleaner architecture. It may be that it all gets rolled into one daemon eventually (called something other than nwamd!), but keeping the functions separate is a helpful model for now. > > 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. > > > I think the key here is what is meant by "support." Please > correct me if I am wrong. The major technical problem in > "supporting" the above network technologies is that we need > to automatically detect such set up and do the proper things. > And this requires many new new pieces of code and we decide > to defer this to phase 2. It also requires a more complex UI. > As I asked in a previous email, what is the problem of having > a "static" configuration which has no automagic part? NWAM > (note not nwamd) still can set up such configuration. How to > do that (it can still be done by nwamd if deemed appropriate) > is an implementation detail. The important part is that NWAM > is not disabled. And all the non-automagic changes of NWAM > are still in use. We are not creating two sets of network > configurations, which IMHO are confusing to people. I think this is in fact a matter of semantics. I absolutely agree that for phase 1, we should have a "static" mode and an "automagic" mode. I absolutley disagree that they should both be called NWAM. Regardless of what internal project is responsible for the changes, NWAM means network auto-magic, and should only refer to the automagic features. > > 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? > > > Why is it not possible? You're asking the same question I was, but from the other side! I didn't make any claims that it wasn't. I was proposing a change to the existing design; sounds like you agree with it. > > 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. > > > Let's step back and ask another question first. The above > decision by the sys admin can still be done when NWAM is > enabled. Otherwise, I think we have a problem :-) And I > believe we have discussed this in length in the mailing list. > So why can't we have the same way for a sys admin to make > the above decision with or without the automagic part, which > just means a static configuration? As I said before, I think the administrator does need to have the choice, and I think our design offers that choice. I do *not* think we should say NWAM is enabled all the time, for the reasons I gave above. -renee > > 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? > > > This is an implementation detail. And I suspect that it is > better to have the same daemon handling both automagic and > static configuration. I think most of the code can be shared > anyway. But how this is done should not affect the decision > that NWAM should not be disabled (in some sense, it simply > cannot be disabled as the new network configuration framework > is now NWAM...) > > > > -- > > K. Poon. > kacheong.poon at sun.com > > _______________________________________________ > nwam-discuss mailing list > nwam-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-discuss
