[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). This is problematic for
two reasons: It invalidates a lot of existing sysadmin
knowledge, scripts and tools, and it means that the
networking system can't be extended without first extending
NWAM (i.e., we can't use vlans now because NWAM doesn't
support vlans yet, extrapolate for honeycomb and other
new technologies...)
]
James Carlson wrote:
> John Plocher writes:
>> [reduced audience]
>
> It might be worthwhile to have these sorts of basic discussions on the
> project's mailing list. If you're having doubts about it, then I
> suspect it's possible that others are having similar doubts. Getting
> those things out in the open in one place -- and answered there --
> would be much more practical for everyone involved.
I was trying to be sensitive to all of Renee's time I've already
taken. I just reposted the previous thread to the wider alias.
>> if (location change needed) {
>> save_current_config_as(current_location);
>> apply_new_config_from(new_location);
>> }
>
> Sort of. I think the right answer is that utilities that modify
> "saved" configuration write that data into the current location
> storage.
>
> That removes the need for save_curent_config_as (and also eliminates
> any question of how temporary changes [e.g. ifconfig] factor in).
I think we are saying almost the same thing, but (again) I wasn't
clear :-(
Today, the "current location storage" is /etc/files, smf properties
and the like, and this project defines a "Repository" under /etc/nwam.
I was thinking of save_current_config_as() as the "smurf" function
that JBeck mumbled about, and not a dynamic probe for temporary
changes:
current_config_as() {
incorporate contents of /etc/hostname.*,
/etc/resolv.conf, /etc/net/ipsec..., ...,
into whatever persistent Repository
is used by NWAM.
}
I was explicitly not implying that tools should write directly into
the NWAM repository.
> 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)
How about editing /etc/resolv.conf (I'd hope not)
Creating a /etc/hostname.bge0 file (ditto)
Permanent in my mind is "if I do something, and then reboot,
will that something persist?"
Temporary is "no, it won't".
> 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.
> 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.
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.
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...
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.
Changing Locations would then entail
copy/rdist/whatever the list of managed files from /etc to
the .../Locations/foo subdir, then
copy the stuff from .../Locations/new back out into /etc, then
kick the various smf network services to tell them to restart.
Adding support for vlans (etc) would simply mean adding the list
of vlan config files and smf "kicks" to the list of things managed by
NWAM. The "need to invent a GUI", "need to invent auto-triggers",
and other related complexity becomes a followon or parallel effort.
It seems easier to understand and build auto-whatever on top of a
solid "manual location switching" base than it is to boil the whole
ocean trying to do an interconnected everything.
> The manual location usage idea is interesting, though I agree that
> it's a bit of a hack to use it that way, and that we certainly
> shouldn't try to advertise it as any sort of versioning system. Using
> "current" and "trial" would work, but trying to have twenty of them
> arranged by date would probably be a mess.
I was thinking more along the lines of a safety net for admins
as they migrate to higher performance or more feature-rich
configurations, and not a version control system:
"simple, static IP on one net", "multihomed", "multihomed IPMP",
"IPMP with VLANS", "fallback for when ITOPS screws up the NIS maps",
"my networking with comcast", "my networking with pacbell",....
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. 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.
-John
