John Plocher writes:
> [Summary: I added the following to the case's issues file:
>
> jmp0: I have an uncomfortable lingering impression that NWAM
> equates to a completely disruptive change in how networking
> configuration is performed (was /etc/files, SMF services and
> related admin commands, now is NNWAM cli/gui and
> NWAM-library-aware commands only).
That's not true. The non-NWAM-library-aware commands are still
intended to be supported and must still work as they did before. If
they don't work, then that's a bug.
In fact, achieving that level of conformance is the reason why NWAM
(for standard Solaris) is still disabled by default, and why it's only
enabled in distributions that are "experimenting" with interfaces.
I *think* you might be trying to say that you believe that the project
team hasn't done enough planning to make that future convergence
possible. If so, then the long term result will be that there will be
two system-level profiles: one for "automatic config" and another for
"admin gets down-n-dirty with vi." That would represent a failure for
the project team, but I don't believe that it's a disruption to the
user, because he just keeps on doing what he did before.
> > A change in location will cause a loss of any temporary changes you've
> > made. That's exactly what we expect.
>
> The difference may be in what you think of as a temp change.
>
> Is it running ifconfig? (probably)
Yes.
> How about editing /etc/resolv.conf (I'd hope not)
Probably not, but that's not this project. That's NWAM Phase 2. It'd
be much harder to review this project if we had to invent all of the
subtle components needed for a future project at the same time. As it
stands, NWAM Phase 1 is very late.
My guess is that one of two things eventually happens to
/etc/resolv.conf when Phase 2 arrives:
- The file is treated as part of the current location. When we
change locations, the current contents of the file are put into
the repository, and the soon-to-be-current one from the repository
is put in place.
- The file is ignored completely. It's no longer an administrative
interface, and some other interface (perhaps not even from NWAM!)
has subsumed its role. This is the sort of Major release change
that Glenn was talking about.
I don't know which of those actually happens. That's not this
project.
If I had to bet, I'd say that the first one is slightly more likely,
but Phase 2 is far enough out that anything's possible.
> Creating a /etc/hostname.bge0 file (ditto)
Yep; ditto. My guess is that /etc/hostname.* eventually goes away.
> Permanent in my mind is "if I do something, and then reboot,
> will that something persist?"
>
> Temporary is "no, it won't".
Exactly. A new twist to this, though, is the concept of location.
Permanent: "if I do something, and then reboot, and I'm still in the
same location, that thing will persist; it will also persist if I
leave the current location and then come back."
Temporary: "if I reboot or change locations, then I lose that thing."
> > As things stand now, if you edit /etc/ configuration files and you use
> > NWAM, you're on your own. You're not supposed to do that.
>
> This fails the "least surprise" test, and is IMHO a level0 issue
> because it says that the traditional admin way of doing things is
> now forbidden. I'd rather see something that is evolutionary than
> disruptive here.
That's why NWAM Phase 1 is not the default.
I don't agree that it's a level zero issue at all. It would be one if
we were _forced_ into making NWAM the only way to configure the
system. However, as things stand, it's not the only way to configure
the system, and we're intentionally not making it one. It's not even
the default.
(I'm saying 'we' here even though I'm not formally part of the project
team. I'm just in the same group ...)
The "traditional" scheme will exist as long as NWAM is unable to
fulfill the entire role that the older scheme plays. That's the plan.
> > If you store something outside of a "location," and the location
> > mechanism can overwrite it, then what you've done is temporary.
>
> or there is a bug/hole in the architecture or design of Locations.
If there's a bug, then file one. I don't think we're talking about
bug tracking here, but rather architecture.
> The Locations mechanism we have in this case seems to be creating a
> new, parallel set of persistent admin config data storage that
> conflicts with the existing ones - most of which are defacto committed
> interfaces.
I disagree. In what respect does anything in the case as described
conflict with any committed interface?
I think we're going to need details. What is the conflict? What
thing doesn't work as it did before?
> Speaking from experience, this is not an area where being disruptive
> is a good thing. Adoption and use of NWAM on servers will be a
> non-starter if using it means admins have to start from scratch to
> relearn network admin...
You may be surprised to find that folks on the project team have some
experience in the area as well and understand very well what
disruption here means.
And, no, nobody's expecting that admins will have to learn things
again from scratch. Some things will likely change, but in many cases
the change will be: "you used to have to mess with this to make it
work; now you don't have to do anything at all."
> My simplistic /conceptual/ view of Locations started with something
> simple (a directory like .../Locations/foo) and a list of the various
> config files that needed to be managed.
That doesn't sound like a concept to me; that sounds like a specific
file-oriented design. It also sounds like it's in conflict with the
goal of eventually merging with the SMF profiles project ... but I
think low-level design issues should be hashed out on the project
team's mailing list.
> Even though they are called "Locations", they are really nothing
> more than Named Configuration sets. Both your and Erik's reactions
> reinforce my belief that the "automatic" mindset is obscuring some
> basic architecture here.
I fundamentally disagree with that. There's no obscuration.
Yes, they're are named configuration sets. And, yes, one of the
"policies" you can use to switch between them could be manual
intervention.
Yes, you could do as you describe.
However, the point of the project is to be able to support automatic
configuration. We're not going to drop that feature out of the
definition of the project just because there's someone out there who
doesn't want to use it. There are others who *do* want it, and it's
an important part of the projects goals: the project is not successful
if automatic configuration is not supported.
The set of features to support and the priority of them is essentially
a marketing and business call, not architecture.
I agree that the project needs to be "complete" on its own, but I
don't agree that changing the definition to remove automatic
configuration will actually accomplish anything like that goal. The
only thing it'll do is terminate the project.
> Yes, one can use subnet-knowledge based
> triggers to auto-change to a new Location, and yes, it would
> be good if a particular Location could take advantage of dynamic and
> automatic network configuration (dhcp, wifi, ...), but there is
> still value in a partial system that doesn't do any automatic, but
> does do a complete job of handling manual locations.
I agree that there's value in that. I agree that it would be good for
some customers, and very useful. However, that partial system does
not fill the _requirements_ for the project that's under review, and
the requirements are being driven much more by OpenSolaris (laptop and
desktop usage) than by other markets.
I don't think that PSARC's mailing list is the right place to try to
do technical marketing. But if you have concerns about how the
marketing aspect is being run, and the priority given to particular
feature sets, then I urge you to take that up with management. I
believe the best person to talk with would be Victor Nelson.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
