Liane Praza wrote:
On 05/12/10 16:37, Mark Haywood wrote:
Liane Praza wrote:
On 05/12/10 12:51 PM, Edward Pilatowicz wrote:
some quick questions.
how does this functionality interact with different network management
services, specifically network/physical:nwam and
network/physical:default? is network configuration only supported for
one of these methods? if so, what happens if that method is disabled
and another one is in use?
does enabling the svc:/network/dns/install have any interactions with
nsswitch.conf(4)? for example, is it an error to enable
svc:/network/dns/install if dns is not enabled via nsswitch.conf(4).
will the svc:/network/install service reconfigure interfaces that
already have an existing configuration?
will the svc:/network/install service ever unconfigure interfaces? for
example, if no install_ipv4_interface and install_ipv6_interface
values
are specified, and the svc:/network/install service is brought online,
will it do anything?
I echo Ed's sentiments and generally have a concern about install-only
interfaces. (And services named as such.)
It'd be better to consider the direction that the interfaces are
likely to evolve in long-term and put the properties on the
appropriate services. It wouldn't have to change the implementation a
great deal for now, but leaves an interface that has a much better
chance of evolving. It also allows the opportunity for configuration
switching of the style that ipfilter uses now: either the properties
or the files are authoritative, and that's switchable and predictable
rather than inferred.
I understand your concern. If network interfaces were currently modeled
in SMF, then this case probably wouldn't be necessary. Modeling the
network interfaces in SMF is not currently a committed project but is
under investigation. However, given the uncertainty in its
implementation we are trying to provide Install with interfaces that
meet their needs in the near-term. If an SMF implementation of network
interfaces comes into existence before Solaris Next, then the proposed
interfaces will be changed. It such an implementation comes into
existence after Solaris Next ships, then the proposed services and their
properties can be used to initialize the new implementations.
Does the segregation of the properties to an "install" service help
with the forward compatibility goals? I don't see that it does, but
maybe I'm missing something.
If there was a better place to hang these properties, I'd propose
hanging them there. OK, maybe the DNS properties could be located in the
dns/client service. However, I don't believe libresolv is ever going to
use SMF properties directly for its configuration. And placing
properties there seems to be misleading to me.
(I believe that with the modifications I suggested, this project could
currently be useful at more points in time than just install, which
would seem valuable, including for layered administration tools like
Visual Panels. The set of configuration parameters deemed necessary
for serialization at install time are likely to significantly overlap
with the most common configurations, so I believe there's value in
allowing the properties you're introducing to be persistently
authoritative.)
And I don't believe that I argued your point at all. What I said was
that until we get there, this proposal will allow the install team to
move forward. I don't believe modeling network configuration will be
trivial. If the Install team has to wait for us to do that, then I think
we might be impact the Solaris Next schedule.
liane
_______________________________________________
opensolaris-arc mailing list
[email protected]
