Sebastien Roy wrote:
> Garrett,
>
> On Wed, 2008-04-23 at 10:42 -0700, Garrett D'Amore wrote:
>
>> Seems like a good idea to me.
>>
>> The only caveat here is that I think it should remain possible to access
>> NICs by hardware driver name, if folks so choose (i.e. configure the
>> vanity names by default, but allow admins who are familiar with and may
>> prefer the hardware names -- for whatever reason -- to do so.)
>>
>
> That is not compatible with the design of the system. A datalink
> interface has a name (only one), and it's accessed by that name. One
> can view details of a physical datalink such as the device underneath by
> typing "dladm show-phys". One could rename a datalink back to a
> different name if they don't like the default name chosen by the system.
>
"Renaming" addresses my concern. I.e. the administrator can elect not
to use the vanity names if he so chooses.
>
>> One goofy issue here is interface stability. I think part of the
>> problem is that we don't really know what the classification of Indiana
>> is for interface stability. It seems to fluctuate between a Minor and a
>> Major release. If its a Minor, then notification of changing names in
>> the release notes seems appropriate.
>>
>
> I don't think that this is relevant. There is no upgrade path from a
> previous version of Solaris to Indiana. On a fresh install of Indiana,
> regardless of the release taxonomy of Indiana, I don't think there would
> be a problem using a naming scheme for network interfaces which is
> different from other releases of previous versions of Solaris.
>
> On upgrade from one Indiana release to another (or more specifically
> when updating the appropriate existing Indiana package), then I think
> preserving existing interface names would be desirable to not break
> already installed system and application configuration.
>
See, the path from S10->Nevada->Indiana is not well known. Right now it
doesn't exist. Does it hold true that it will never exist? Its hard to
say, because until now Indiana has only been a prototype distribution
and red-headed step child of the Solaris lineage.
>
>> Perhaps one way to address the potential stability would be to submit a
>> possible "EOF notice" for "hardware names" indicating that the default
>> names of network devices in the future may change to net0... etc. (This
>> is really a release notes change for some future S10 update....) (That
>> may require Clearview be available in said S10 update, however.)
>>
>
> What do changes in OpenSolaris have to do with Solaris 10? In any case,
> if Indiana has release notes, then it would certainly make sense to put
> something in there to familiarize Indiana users with new features, but I
> don't see how that is related to Solaris 10 or what the Clearview
> project decides to back-port in the future (if anything).
>
Again the problem is figuring out the relationship between
OpenSolaris/Indiana and S10. If Indiana is an entirely new product with
no compatibility guarantees then I agree. If however, it is going to be
part of the main Solaris product line, then upgrade (and the issues I
raised) comes into play.
A release note in an S10 update could be seen as CYA insurance for which
ever path Indiana (or for that matter any hypothetical post S10 release)
takes.
I know there have been some internal plans on this, but its not clear
that any direction has been finalized. As yet, large portions of
Indiana have not come before ARC, and significant compatibility issues
between it and S10 exist. So far, it hasn't mattered because Indiana
wasn't a real 'product' yet.
I wonder if anyone is keeping track of the compatibility issues between
Indiana and Nevada. Some day knowing the full set of them may become
important.
Anyway, my comments here were merely advisory -- I'm actually happy with
the idea of changing to netXX, I just want to make sure that if there
are ever going to be any compatibility issues we have the ground work in
place to deal with it.
-- Garrett
