On Wed, 2008-04-23 at 11:15 -0700, Garrett D'Amore wrote: > 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.
Correct; I misinterpreted your desired requirement. > > > > >> 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. It's certainly an outstanding question. I don't know the established rules for Indiana integration, nor if there are any, but my understanding was that it was an appropriate vehicle for introducing innovative changes (incompatible or not). Others have done so, and I would certainly be confused if this proposed change were to be held to a different standard than other changes in Indiana. > > > >> 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 see what you mean now, but I don't think this is related to whether features integrated by Clearview in OpenSolaris make their way into Solaris 10. Anyone can put a heads-up in Solaris 10 release notes warning users of a future incompatible change. > 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. At the same time, I don't really see the benefit of yanking out cool features out of Indiana in the future because of compatibility concerns with Solaris 10. As of 2008.05, the Indiana ship will have sailed along with its changes (incompatible or not) from other Solaris versions. This discussion probably needs to be lead by the Indiana project team and whoever decides to productize something based on Indiana. > 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. Sure. > > 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. Let's start with Indiana release notes and figuring out what to do about upgrades from one version of Indiana to another. Figuring out what to do about incompatibilities between s10 and Indiana sounds like a bigger problem that I don't personally want to be responsible for in this context. Thanks, -Seb
