On Thu, 2006-10-19 at 12:45 -0700, Raoul Carag wrote:
> I just posted a revised version of the Link Names documentation based on
> feedback from the community on the previous draft.
>
> http://www.opensolaris.org/os/project/clearview/docs
>
> Some modifications were also made to address comments on the section
> about zones migration that involve administratively-chosen names.
>
> As usual, your comments are welcome. Please send feedback to the
> clearview alias.
Excellent doc. Raoul. Here are some comments:
General:
* The terminology "data link" is more precise than "link", as "link" is a
term that is used in many contexts (file systems, locking, compilation,
kernel modules, etc.). The term "link" is used quite a bit throughout the
document, and it might help to specify "data link" in many cases in order
to train people's brains to think in those terms and to remove any
potential confusion.
Section 1. General Description:
* What topology restrictions are you referring to in the 1st paragraph?
* The term "unrestricted link name" is probably over the top, as the names
are restricted to a specific syntax.
Section 2. Link names and ... Installation
* This is not what the project team has planned, but at the same time, the
plans may change. We had planned to use vanity names by default for fresh
installs using a scheme such as net0,net1,.... For upgrade, names would
remain the same as before.
Section 3. Rules for Valid Link Names
* You say, "The first or last character of the name must not be a digit."
this is incorrect, as a link name _must_ end in a digit. I think that the
string is taken from the dlpi man page, which is describing the
restriction on the driver name (or the non-PPA portion of a link name).
* "unique" isn't defined here, it should be unique within the system.
Section 5.1.1
* There may need to be some initial step here when NWAM comes into being.
The fact that NWAM will automatically plumb IP on every available physical
data-link by default will mean that the administrator will somehow need to
tell NWAM to keep away from the data-link while it's being renamed. I'm
not sure how this is going to work. This is also kind of awkward since
NWAM is scheduled to deliver after UV, so I'm not sure what the plan is
for this kind of documentation.
* The description for show-phys -P states that it shows information about
links that are no longer available. Shouldn't that be "physical devices"
that are no longer available?
* Instead of "link1" and "link2", how about "old_linkname" and
"new_linkname" or something like it?
* linkn is confusing. Since "linkn" describes both "link1" and "link2", one
would assume from its description that the data-link is assigned both
"link1" and "link2" as names. Instead, it would be clearer for there to
be two new items here:
old_linkname Name that is originally assigned to the physical device.
new_linkname Name that the administrator wishes to assign to the
physical device.
(replace "old_linkname" and "new_linkname" with whatever you see more
appropriate)
* I'm not sure if steps 4-7 are appropriate for this document. Isn't there
already a section in the admin. guide that describes how to configure IP
interfaces (which will change drastically with NWAM)? Instead, couldn't
this be replaced with the following step:
4. If the data-link is meant to be used for IP communication, configure IP
interfaces on the data-link as described in "bla bla section bla" using
the newly assigned data-link name.
Section 5.1.2:
* The example has an incorrect ifconfig syntax. You need to first plumb the
IP interface before assigning an address to it. Also, you can either use
"netmask +" to automatically assign a netmask, or "netmask 255.255.255.0"
to explicitly assign a netmask, but not both. You also need to bring the
IP interface "up" to make it useful.
* The hostname.* files are unnecessarily complicated. Just have the
addresses in the files. The netmasks will take care of themselves, and
are configured through /etc/netmasks if the administrator cares.
* It doesn't make sense to put the name of the data-link or IP interface in
/etc/hosts. Hostnames go in there. A more sensible /etc/hosts might be
(note the ::1 in there, it's part of /etc/hosts as of recent builds of
Nevada):
127.0.0.1 localhost
::1 localhost
192.168.84.72 myhost
192.168.84.3 myhost-netmgt
You could just put "myhost" and "myhost-netmgt" in the /etc/hostname.*
files instead of IP addresses given the contents of the /etc/hosts file.
Section 5.2.1:
* Step 3's description isn't quite right, it should be, "create a VLAN
interface on one of the links" or something like that.
Section 5.3:
* Step 2 is strange. If I'm just configuring autopush, why would it be
necessary to rename the link. I think this step should go.
* Step 3 is technically innacturate. This does not actually push anything.
It configures the system such that the module specified will be pushed on
the steam when the data-link is opened in the future.
Section 5.5.1:
* The step that actually migrates the zone is missing, or at least a
reference to documentation on how to do this is missing.
* Reminder: we need to make sure that this works for some set of zones
before putting this in official documentation. It's possible that it will
only work for some very simple zone configurations, where nothing else
about the zones is different. Anyway, it warrants further experimentation
and analysis.
Section 5.6.1.1:
* In step 2, show-link doesn't show what's been plumbed by IP. That's done
using ifconfig -a. Again, NWAM may throw a wrench into these instructions.
Thank you,
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
