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.
(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.)
liane
_______________________________________________
opensolaris-arc mailing list
[email protected]
