Renee Danson wrote:
> 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,
Yes, I think phase 1 should do more.
> 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.
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.
> 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.
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.
> 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?
We can and we should.
> 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?
> 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?
> 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
