On Wed, 2010-06-02 at 20:20 -0400, Mark Haywood wrote:
> Garrett D'Amore wrote:
> > On Wed, 2010-06-02 at 15:01 -0400, Mark Haywood wrote:
> >
> >> On 06/ 2/10 01:43 PM, James Carlson wrote:
> >>
> >>> James Carlson wrote:
> >>>
> >>>
> >>>> That's the part that still confuses me. I'd expected that, just as
> >>>> installation was "based on" NWAM in OpenSolaris, this would be the
> >>>> pattern for the future as well.
> >>>>
> >>>>
> >>> And, now, I understand Mark's last reply, where he said:
> >>>
> >>> I and the folks working on install don't believe that NWAM is yet
> >>> functionally complete enough to be the default service for our
> >>> Enterprise customers. And therefore, we chose to provide install with a
> >>> mechanism for configuring an initial physical:default configuration.
> >>>
> >>> OK; that's the missing bit. It *is* intentionally physical:default, not
> >>> just for install, but also (potentially) for the running system. The
> >>> original proposal provided that hint in the XML-encoded profile, but
> >>> never came out and said it directly.
> >>>
> >>> It was a long drive to figure out that this was intentional and not a
> >>> "bug." Could something to the effect of "for AI, and for the time
> >>> being, we're expecting to disable NWAM and use physical:default on the
> >>> installed system" be added to the spec?
> >>>
> >>>
> >> It is intentional that the interfaces provided by this case will only
> >> have significance for physical:default. And I think that it is also
> >> correct to say that for AI, more often than not, we expect NWAM to be
> >> disabled. However, an administrator can do whatever she likes in an SMF
> >> profile. If she wishes to enable NWAM *and* define the static
> >> configuration, then we can't prevent that. We can, however, display a
> >> message that indicates that she just did something that was probably
> >> nonsensical. We can also document the network/install service to make it
> >> clear that the properties are used to configure static configurations
> >> for physical:default only.
> >>
> >
> > I think the idea that NWAM is typically *not* enabled by default with AI
> > is unfortunate. Many sites may choose to deploy AI in environments
> > where the network infrastructure (dhcp) provides correct and reasonable
> > configuration even for systems that have more or less "fixed" IP
> > configuration. As such, NWAM offers an easier configuration for
> > end-users.
> >
>
>
> NWAM isn't a requirement for using DHCP to gather configuration
> information. This proposal supports DHCP as a source for network
> configuration via the network/physical:default service.
>
>
> > I view network/physical:default as an unfortunate artifact, representing
> > a deficiency in nwam, that I had hoped would one day be corrected.
> >
> > Having two totally different and totally incompatible network
> > configuration schemes is a recipe for much end-user confusion and many
> > service calls.
> >
>
>
> And from one of my earlier responses on this thread:
>
> "Does this mean that we (Solaris Networking) aren't working on doing
> away with the separation between physical:default and physical:nwam? No.
> That work is being planned. When completed, I believe that the
> interfaces proposed by this case will be changed appropriately. "
Ok, sorry for not reading the entire thread....
As long as we all agree that this situation is basically a "bug" that
will be rectified by future work to eliminate physical:default, I'm ok
with it.
However, I've not read enough of the case to feel comfortable giving it
a +1 at this time.
- Garrett
_______________________________________________
opensolaris-arc mailing list
[email protected]
