From carlsonj@phorcys.east.sun.com Thu Oct 23 07:41:23 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NEfNE1001909 for ; Thu, 23 Oct 2008 07:41:23 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9NEfMG4005126; Thu, 23 Oct 2008 10:41:22 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9NEfMlK005123; Thu, 23 Oct 2008 10:41:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18688.36114.874148.943857@gargle.gargle.HOWL> Date: Thu, 23 Oct 2008 10:41:22 -0400 From: James Carlson To: psarc-ext@sac.sfbay.sun.com cc: renee.danson@sun.com Subject: 2008/532 NWAM Phase 1 -- materials and status change X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 499 I've deposited materials from the project team in the 'inception.materials' directory and fixed two problems with the IAM file: it was set to "closed" Exposure (the 1-pager clearly said "open;" I don't know what happened there), and the inception is on 10/29, not yesterday. -- James Carlson, Solaris Networking 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 From erik.nordmark@sun.com Thu Oct 30 09:39:44 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9UGdhlq007718 for ; Thu, 30 Oct 2008 09:39:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9UGdKvB013047; Fri, 31 Oct 2008 00:39:40 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9K007078Y3NG00@nwk-avmta-2.sfbay.sun.com>; Thu, 30 Oct 2008 09:39:39 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9K004CO8Y2PQ50@nwk-avmta-2.sfbay.sun.com>; Thu, 30 Oct 2008 09:39:38 -0700 (PDT) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9UGdbZv444036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 09:39:37 -0700 (PDT) Date: Thu, 30 Oct 2008 09:39:32 -0700 From: Erik Nordmark Subject: PSARC/2008/532 NWAM To: psarc-ext@sun.com Message-id: <4909E344.8010808@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.16 (X11/20080923) Status: RO Content-Length: 1915 I found this issue in the caselog > seb-0 Assuming that the future of network configuration is > NWAM-only, and that the existing mess that comprises > network/physical:default will eventually go away, are there > design, architectural, or even scoping constraints that this > project imposes on other current and future project? For > example, I know of a current larval project planning on > replacing ifconfig and /etc/hostname* files as an IP interface > configuration tool. If nwamcfg and its GUI are the future, > should that project stop what it's doing? I don't think that project needs to stop what it is doing, but some care is needed around the fixed configuration where there is overlap. One of the key things we need and that NWAM is delivering is the dynamic dependencies that feed into the configuration i.e., the ability to specify a matching criteria for a location and which configuration should apply in that location. Separately we need to make fixed configurations easier to handle by building an infrastructure which can replace ifconfig and /etc/hostname* so that we can have a simple way to setup persistent fixed IP configuration. As part of doing the latter piece we definitely need to think about the intersection with nwamcfg for the case of a single, fixed location. But I don't think that would be too complex. One possibility is that NWAM and nwamcfg grows the ability to specify the full IP feature set (link aggregations, VLANs, IPMP groups) in which case an invocation of a ipadm cli could be implemented by just invoking NWAM to update the fixed location. But there might be other ways to fit things together. In any case, the work to have think CLIs on top of libraries means that we will be able to reuse things even if we end up with a different CLI targeting the fixed server configuration case and nwamcfg+GUI for the nomadic case. Erik From John.Plocher@Sun.COM Fri Oct 31 10:32:31 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9VHWVF0025356 for ; Fri, 31 Oct 2008 10:32:31 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9VHWVSJ012234 for ; Fri, 31 Oct 2008 10:32:31 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9VHWPsI014540 for ; Fri, 31 Oct 2008 10:32:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9M00G014FWMW00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Fri, 31 Oct 2008 10:32:25 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9M00HTX61S8N40@fe-sfbay-10.sun.com>; Fri, 31 Oct 2008 10:32:16 -0700 (PDT) Date: Fri, 31 Oct 2008 10:32:16 -0700 From: John Plocher Subject: Re: 2008/532 NWAM Phase 1 - plocher followup from inception review In-reply-to: <18688.36114.874148.943857@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: psarc-ext@sac.sfbay.sun.com, Renee.Danson@Sun.COM Message-id: <490B4120.2010007@Sun.Com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_GZYyxZxw3SiaWawac2iEbA)" References: <18688.36114.874148.943857@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 2561 This is a multi-part message in MIME format. --Boundary_(ID_GZYyxZxw3SiaWawac2iEbA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I followed up to the inception review with an offline email to Erik, Jim and Renee that, in hindsight, may be of interest to all. The conversation is attached. -John --Boundary_(ID_GZYyxZxw3SiaWawac2iEbA) Content-type: message/rfc822; name="Attached Message" Date: Thu, 30 Oct 2008 14:50:55 -0700 From: John Plocher Subject: Re: PSARC/2008/532 NWAM In-reply-to: <4909E344.8010808@sun.com> To: Erik Nordmark Cc: Renee Danson , James Carlson Message-id: <490A2C3F.9000304@Sun.Com> X-Envelope-from: John.Plocher@Sun.COM X-Envelope-to: okie@jurassic-x4600.eng.sun.com, psarc-ext@sac.sfbay.sun.com MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT References: <4909E344.8010808@sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) [reduced audience] Erik Nordmark wrote: > we definitely need to think about the > intersection with nwamcfg for the case of a single, fixed location. I spent a bunch of time after the PSARC meeting yesterday doing a poor job of trying to discuss something similar with Renee, but I kept tripping over my own confusion about whether or not I was missing something in the specs or if the project had a blind spot of its own. After re-reading the specs and writing the following, I still have some unease - it seems that the NWAM project has overly blurred the lines between "support multiple locations", "automatic reaction to network changes" and "automaticly changing Locations". On to those "single, fixed location" systems: The desired user model seems clear to me - every system starts out with a single default location managed by NWAM, and for those "single fixed location" systems, they never move. If a system never moves, NWAM's "auto detect if I moved and then react to it" functionality never gets used. That is not to say that there would never be a use for NWAM's ability to create and manually switch between multiple network configurations on a big server. For example, if the admin wished to try out a new network configuration (different vlans, enable IPMP...), they might create a new "pseudo location" sandbox to play in as a clone of the current location, knowing that they could always revert back to their known good previous "location" if something didn't work out. From a /user's perspective/, the config data flow might be Status: RO thought of as: The system is always in some "NWAM location" or another. The user can make changes to the system's network config using all of the various sysadmin tools, and all will be well. Some of those tools (NWAM-gui...) may provide a richer or more-feature-full experience, but for doing old things, the existing old tools should work just fine. One difference from legacy Solaris is that there now is the notion that all the network config data is associated with a Location, a system can have multiple Locations defined, and the admin can change between those Locations, either manually or via some sort of auto-triggers policy. Another is a new mechanism (NCP) to add dynamic, policy driven interface selection, dependencies and setup based on external stimulii. It should be noted that the "change my Location" feature is only "config data loss" safe if it can ensure that all the current configuration's network admin data has been safely collected and associated with the current location before it gets overwritten it with the config data for a different Location[*]. In effect, the change location feature needs to behave like: if (location change needed) { save_current_config_as(current_location); apply_new_config_from(new_location); } Repeat as needed as a system is physically or logically moved between locations. In this world view, there is no difference between ":physical" and ":nwam" - the former is simply a NWAM world with only one location. I'm not at all certain that this is what was presented in PSARC yesterday - there were comments that led me to believe that one could only modify a system's config via special NWAM tools, that changes made outside those tools would be lost, and that much of the complexity was driven by the need to provide automated config change policies that took the user/admin out of the loop. I got the impression that the algorithm was more like: ... network config changes made with new NWAM tools will update the associated NCP and Location profiles, but other changes (say, editing traditional /etc/ config files) won't. ... if (location or NCP change needed) { // Note that the existing config files will be clobbered // by whatever Network and Location Profiles are stored // in NWAM's Profile Repository. apply_new_config(to); } After sleeping on it, it seems that the big difference between these views is that NWAM does not (can not?) slurp the current location's config data into persistent storage before it overwrites it with data from a new location; it instead seems to insist that everyone use only the new NWAM-aware admin tools. A separate thread was a concern that the expressive ability of the current net admin tools was insufficient to properly convey the new semantics introduced by NWAM; the feedback was that updating and/or replacing those tools should not be presumed to be impossible, and that doing drastic change /now/ might be easier than /later/. -John ---- * I would expect this to be the persistent config data(e.g, the various /etc config files and the like, and not the transient stuff exposed via "parse the output of commands like ifconfig -a". --Boundary_(ID_GZYyxZxw3SiaWawac2iEbA) Content-type: message/rfc822; name="Attached Message" Return-path: Received: from fe-sfbay-09.sun.com ([192.18.34.119]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K9K00LH9P18SKD0@sfbay2-mail1.sfbay.sun.com> for plocher@sfbay2-mail1.SFBay.Sun.COM; Thu, 30 Oct 2008 15:27:08 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9K00I01OT56800@fe-sfbay-09.sun.com> for plocher@sfbay2-mail1.SFBay.Sun.COM (ORCPT John.Plocher@sun.com); Thu, 30 Oct 2008 15:27:08 -0700 (PDT) Received: from phys-sfbay2-1.sfbay.sun.com ([129.145.47.16]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K9K006BBP18L250@fe-sfbay-09.sun.com> for plocher@sfbay2-mail1.SFBay.Sun.COM (ORCPT John.Plocher@sun.com); Thu, 30 Oct 2008 15:27:08 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K9K00LH7P18SKD0@sfbay2-mail1.sfbay.sun.com> for plocher@sfbay2-mail1.SFBay.Sun.COM (ORCPT John.Plocher@sun.com); Thu, 30 Oct 2008 15:27:08 -0700 (PDT) Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9UMR89s041889 for ; Thu, 30 Oct 2008 15:27:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9UMR0eK009743; Thu, 30 Oct 2008 15:27:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9K00L5XP14VZ00@brm-avmta-1.central.sun.com>; Thu, 30 Oct 2008 16:27:04 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.68.130]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9K00LCDP139J10@brm-avmta-1.central.sun.com>; Thu, 30 Oct 2008 16:27:04 -0600 (MDT) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9UMR3ZO452598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 15:27:03 -0700 (PDT) Date: Thu, 30 Oct 2008 15:26:59 -0700 From: Erik Nordmark Subject: Re: PSARC/2008/532 NWAM In-reply-to: <490A2C3F.9000304@Sun.Com> To: John Plocher Cc: Renee Danson , James Carlson Message-id: <490A34B3.7030305@sun.com> X-Envelope-from: John.Plocher@Sun.COM X-Envelope-to: okie@jurassic-x4600.eng.sun.com, psarc-ext@sac.sfbay.sun.com MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4909E344.8010808@sun.com> <490A2C3F.9000304@Sun.Com> User-Agent: Thunderbird 2.0.0.16 (X11/20080923) Original-recipient: rfc822;John.Plocher@sun.com John Plocher wrote: > On to those "single, fixed location" systems: > > The desired user model seems clear to me - every system > starts out with a single default location managed by NWAM, > and for those "single fixed location" systems, they never > move. If a system never moves, NWAM's "auto detect if > I moved and then react to it" functionality never gets used. Correct. But we've also discussed using part of NWAMs machinery to verify a location. For instance, it is possible to use DHCP to essentially ask what subnet is used on a link without using DHCP to assign an IP address. If the subnet doesn't match the statically assigned IP address then something is wrong (like the last time AT&T rewired jurassic and got the wires wrong) That, and similar verification for link aggregation and IPMP, can be quite helpful for fixed systems. > That is not to say that there would never be a use for > NWAM's ability to create and manually switch between > multiple network configurations on a big server. For example, > if the admin wished to try out a new network configuration > (different vlans, enable IPMP...), they might create a new > "pseudo location" sandbox to play in as a clone of the current > location, knowing that they could always revert back to their > known good previous "location" if something didn't work out. I'm not sure I'm confortable with applying locations to that purpose. beadm does a better job of handling changes that can be reverted. If we make NWAM be the "configuration versioning system" we'd be on an interesting slippery slope IMHO ;-) > From a /user's perspective/, the config data flow might be > thought of as: > > The system is always in some "NWAM location" or another. > > The user can make changes to the system's network config > using all of the various sysadmin tools, and all will be well. > Some of those tools (NWAM-gui...) may provide a richer > or more-feature-full experience, but for doing old things, the > existing old tools should work just fine. Except that vi /etc/hostname.bge0 might be removed as the tool for persistent configuration changes, but that is not part of this case. To make multiple locations and non-nwam tools fit together I think we'd need to state that the non-nwam tools modify the currently used location; there is definitely some more thinking needed in that space. > One difference from legacy Solaris is that there now is the > notion that all the network config data is associated with a > Location, a system can have multiple Locations defined, > and the admin can change between those Locations, either > manually or via some sort of auto-triggers policy. > > Another is a new mechanism (NCP) to add dynamic, > policy driven interface selection, dependencies and setup > based on external stimulii. > > It should be noted that the "change my Location" feature is > only "config data loss" safe if it can ensure that all the current > configuration's network admin data has been safely collected > and associated with the current location before it gets > overwritten it with the config data for a different Location[*]. > In effect, the change location feature needs to behave like: > > if (location change needed) { > save_current_config_as(current_location); > apply_new_config_from(new_location); > } > > Repeat as needed as a system is physically or logically moved > between locations. > > In this world view, there is no difference between ":physical" and > ":nwam" - the former is simply a NWAM world with only one > location. Yes, and that is the direction we are moving. The current case is moving somewhat closer than what we have for NWAM 0.5, but we need more thinking as well as more work to get all the way. Removing the need for editing /etc/hostname* is a different project, which should bring us the rest of the way. > I'm not at all certain that this is what was presented in PSARC > yesterday - there were comments that led me to believe that > one could only modify a system's config via special NWAM tools, > that changes made outside those tools would be lost, and that > much of the complexity was driven by the need to provide > automated config change policies that took the user/admin > out of the loop. I got the impression that the algorithm was > more like: > > ... > network config changes made with new NWAM tools > will update the associated NCP and Location profiles, > but other changes (say, editing traditional /etc/ config > files) won't. > ... > > if (location or NCP change needed) { > // Note that the existing config files will be clobbered > // by whatever Network and Location Profiles are stored > // in NWAM's Profile Repository. > apply_new_config(to); > } > > After sleeping on it, it seems that the big difference between these > views is that NWAM does not (can not?) slurp the current location's > config data into persistent storage before it overwrites it with data > from a new location; it instead seems to insist that everyone use > only the new NWAM-aware admin tools. NWAM can't currently handle all types of IP configuration. There is no support for at least - link aggregations - vlans - IPMP groups Thus NWAM can't pull in an existing IP configuration. I've gone over this with the project team and the result of that was that it didn't seem useful to have NWAM be able to pull in /etc/hostname* configuration given those limitations because it would have to reject the above configurations somehow. Instead, when we can handle all the features, we can transition away from /etc/hostname* to a repository-based approach. NWAM still provides value in the interim, even though the users have to choose between NWAM and /etc/hostname*. > A separate thread was a concern that the expressive ability of the > current net admin tools was insufficient to properly convey the new > semantics introduced by NWAM; the feedback was that updating > and/or replacing those tools should not be presumed to be impossible, > and that doing drastic change /now/ might be easier than /later/. Does "tools" mean the Gnome GUIs, ifconfig, both? Erik --Boundary_(ID_GZYyxZxw3SiaWawac2iEbA) Content-type: message/rfc822; name="Attached Message" Return-path: Received: from fe-sfbay-09.sun.com ([192.18.34.119]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K9M005JE29GMXB0@sfbay2-mail1.sfbay.sun.com> for plocher@sfbay2-mail1.SFBay.Sun.COM; Fri, 31 Oct 2008 09:10:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9M007011TSPX00@fe-sfbay-09.sun.com> for plocher@sfbay2-mail1.SFBay.Sun.COM (ORCPT John.Plocher@Sun.COM); Fri, 31 Oct 2008 09:10:28 -0700 (PDT) Received: from phys-sfbay2-1.sfbay.sun.com ([129.145.47.16]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K9M00JTB2985PE0@fe-sfbay-09.sun.com> for plocher@sfbay2-mail1.SFBay.Sun.COM (ORCPT John.Plocher@Sun.COM); Fri, 31 Oct 2008 09:10:20 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K9M005G2298MXB0@sfbay2-mail1.sfbay.sun.com> for plocher@sfbay2-mail1.SFBay.Sun.COM (ORCPT John.Plocher@Sun.COM); Fri, 31 Oct 2008 09:10:20 -0700 (PDT) Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9VGAJsx018492 for ; Fri, 31 Oct 2008 09:10:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9VGA9Wi028314; Sat, 01 Nov 2008 00:10:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9M00K17292BT00@nwk-avmta-2.sfbay.sun.com>; Fri, 31 Oct 2008 09:10:14 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9M00II128ZXY80@nwk-avmta-2.sfbay.sun.com>; Fri, 31 Oct 2008 09:10:12 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9VGABKY026572; Fri, 31 Oct 2008 12:10:11 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9VGA8AQ026569; Fri, 31 Oct 2008 12:10:08 -0400 (EDT) Date: Fri, 31 Oct 2008 12:10:08 -0400 From: James Carlson Subject: Re: PSARC/2008/532 NWAM In-reply-to: <490A2C3F.9000304@Sun.Com> To: John Plocher , Erik Nordmark Cc: Renee Danson Message-id: <18699.11744.561063.617136@gargle.gargle.HOWL> X-Envelope-from: John.Plocher@Sun.COM X-Envelope-to: okie@jurassic-x4600.eng.sun.com, psarc-ext@sac.sfbay.sun.com MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4909E344.8010808@sun.com> <490A2C3F.9000304@Sun.Com> <490A34B3.7030305@sun.com> Original-recipient: rfc822;John.Plocher@Sun.COM 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. Forcing the project team to have the same private conversation with multiple different groups of people over a long period of time seems like a less useful way to handle these technical questions. > After re-reading the specs and writing the following, I > still have some unease - it seems that the NWAM project > has overly blurred the lines between "support multiple > locations", "automatic reaction to network changes" and > "automaticly changing Locations". Yes, those are three distinct elements to the problem, and they do indeed require different solutions. The different solutions happen to be part of this one project, because supporting multiple locations with no way to handle changes would be pointless, and supporting both of those with no way to detect which one is "best" seems incomplete. The project could be decomposed into separate projects, but I'm not sure if it'd help anything. I don't think the project *team*, though, has confused these separate things. > move. If a system never moves, NWAM's "auto detect if > I moved and then react to it" functionality never gets used. Right. > (different vlans, enable IPMP...), they might create a new > "pseudo location" sandbox to play in as a clone of the current > location, knowing that they could always revert back to their > known good previous "location" if something didn't work out. That seems plausible. There might also be other ways to use "locations," such as with an intentional transition: if you were going from NIS to LDAP (maybe because your name services were just too fast with NIS ;-}), you could have separate 'locations' for those, and then use NWAM policy to determine when each machine switches over. > The system is always in some "NWAM location" or another. Yes. > The user can make changes to the system's network config > using all of the various sysadmin tools, and all will be well. > Some of those tools (NWAM-gui...) may provide a richer > or more-feature-full experience, but for doing old things, the > existing old tools should work just fine. It's unclear what "just fine" means, unless you never change location. > One difference from legacy Solaris is that there now is the > notion that all the network config data is associated with a > Location, a system can have multiple Locations defined, > and the admin can change between those Locations, either > manually or via some sort of auto-triggers policy. Yes. > Another is a new mechanism (NCP) to add dynamic, > policy driven interface selection, dependencies and setup > based on external stimulii. Yes. > 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). > Repeat as needed as a system is physically or logically moved > between locations. > > In this world view, there is no difference between ":physical" and > ":nwam" - the former is simply a NWAM world with only one > location. Yes. That's just not NWAM Phase 1. > I'm not at all certain that this is what was presented in PSARC > yesterday - That was NWAM Phase 1. The removal of ":physical" so that NWAM is the only solution is a future phase. It *cannot* be done now. > there were comments that led me to believe that > one could only modify a system's config via special NWAM tools, > that changes made outside those tools would be lost, and that > much of the complexity was driven by the need to provide > automated config change policies that took the user/admin > out of the loop. I don't think that's actually dissimilar to what you've described. A change in location will cause a loss of any temporary changes you've made. That's exactly what we expect. > I got the impression that the algorithm was > more like: > > ... > network config changes made with new NWAM tools > will update the associated NCP and Location profiles, > but other changes (say, editing traditional /etc/ config > files) won't. > ... Editing /etc/ configuration files is simply an unexplored area. It's something that has been deferred to Phase 2. 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. When NWAM picks up more of the system features in Phase 2, you might be able to factor in /etc/. > After sleeping on it, it seems that the big difference between these > views is that NWAM does not (can not?) slurp the current location's > config data into persistent storage before it overwrites it with data > from a new location; it instead seems to insist that everyone use > only the new NWAM-aware admin tools. Not exactly. The real issue is in distinguishing between "temporary" and "permanent" changes, and where that information is stored. If you store something outside of a "location," and the location mechanism can overwrite it, then what you've done is temporary. > A separate thread was a concern that the expressive ability of the > current net admin tools was insufficient to properly convey the new > semantics introduced by NWAM; the feedback was that updating > and/or replacing those tools should not be presumed to be impossible, > and that doing drastic change /now/ might be easier than /later/. Unfortunately, the NWAM project as currently defined cannot handle the wide range of possible things you can configure on Solaris. That means that forcing big changes now will cause a disaster: it'll make some previously-supported things disappear. Including all of "jurassic." I think that's a non-starter. Those sorts of changes need to be in Phase 2. Phase 1 is already too big, complex, and late. Erik Nordmark writes: > > That is not to say that there would never be a use for > > NWAM's ability to create and manually switch between > > multiple network configurations on a big server. For example, > > if the admin wished to try out a new network configuration > > (different vlans, enable IPMP...), they might create a new > > "pseudo location" sandbox to play in as a clone of the current > > location, knowing that they could always revert back to their > > known good previous "location" if something didn't work out. > > I'm not sure I'm confortable with applying locations to that purpose. > beadm does a better job of handling changes that can be reverted. If we > make NWAM be the "configuration versioning system" we'd be on an > interesting slippery slope IMHO ;-) I don't think that's true. "beadm" causes everything to be saved in a snapshot, including internal application state that happens to be stored in files (e.g., "cookies"). Reverting to a BE snapshot is violent. It takes you backwards in time everywhere, potentially causing a loss of application data. I wouldn't consider it for a trial network configuration change. 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. -- James Carlson, Solaris Networking 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 --Boundary_(ID_GZYyxZxw3SiaWawac2iEbA)-- From John.Plocher@sun.com Fri Oct 31 11:09:38 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9VI9bYg026878 for ; Fri, 31 Oct 2008 11:09:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9VI9Xha013339 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 1 Nov 2008 02:09:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9M001057RZWE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 31 Oct 2008 11:09:35 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9M00LR67RZTP70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 31 Oct 2008 11:09:35 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9VI9ZiO016517 for ; Fri, 31 Oct 2008 11:09:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9M00D017CDNC00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 31 Oct 2008 11:09:35 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9M003ZR7RL7800@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 31 Oct 2008 11:09:21 -0700 (PDT) Date: Fri, 31 Oct 2008 11:09:21 -0700 From: John Plocher Subject: Re: 2008/532 NWAM Phase 1 - plocher followup from inception review Sender: John.Plocher@sun.com To: psarc-ext Message-id: <490B49D1.6080704@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 5967 [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 From carlsonj@phorcys.east.sun.com Fri Oct 31 11:49:21 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9VInKsK027538 for ; Fri, 31 Oct 2008 11:49:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9VInGv9028130; Sat, 1 Nov 2008 02:49:17 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9M00F019M4TI00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Oct 2008 11:49:16 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9M0039Z9M3LA70@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Oct 2008 11:49:16 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9VInF5b027318; Fri, 31 Oct 2008 14:49:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9VInFCH027315; Fri, 31 Oct 2008 14:49:15 -0400 (EDT) Date: Fri, 31 Oct 2008 14:49:15 -0400 From: James Carlson Subject: Re: 2008/532 NWAM Phase 1 - plocher followup from inception review In-reply-to: <490B49D1.6080704@Sun.Com> To: John Plocher Cc: psarc-ext Message-id: <18699.21291.623004.122071@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490B49D1.6080704@Sun.Com> Status: RO Content-Length: 8408 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 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 From Nicolas.Williams@sun.com Fri Oct 31 13:38:04 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9VKc3a2000063 for ; Fri, 31 Oct 2008 13:38:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9VKc1KQ000971; Fri, 31 Oct 2008 13:38:02 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9M00805ENEIJ00@nwk-avmta-2.sfbay.sun.com>; Fri, 31 Oct 2008 13:38:02 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9M008USEND6730@nwk-avmta-2.sfbay.sun.com>; Fri, 31 Oct 2008 13:38:01 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9VKbUmo106267; Fri, 31 Oct 2008 15:37:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id m9VKbU5J106266; Fri, 31 Oct 2008 15:37:30 -0500 (CDT) Date: Fri, 31 Oct 2008 15:37:30 -0500 From: Nicolas Williams Subject: Re: 2008/532 NWAM Phase 1 - plocher followup from inception review In-reply-to: <18699.21291.623004.122071@gargle.gargle.HOWL> To: James Carlson Cc: John Plocher , psarc-ext Message-id: <20081031203730.GA102869@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <490B49D1.6080704@Sun.Com> <18699.21291.623004.122071@gargle.gargle.HOWL> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2014 On Fri, Oct 31, 2008 at 02:49:15PM -0400, James Carlson wrote: > John Plocher writes: > > 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. Originally we had a project to create name service configuration profiles that could be switched around, and the idea was that NWAM profiles would name a name service configuration profile, with NWAM switch name service profiles when the networking location changes. That was project "Duckwater," and it would have been responsible for delivering the mechanism for specifying multiple DNS resolver configurations (amongst other things) and switching them around. That project is on hold for the forseeable future. I don't know what NWAM will be doing in the meantime about name service configuration. > 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. That would be good. > - 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. That would be good too provided that NWAM was aware of it and knew how to change the DNS resolver configuration. My suggestion would be to wait for Enhanced SMF Profiles and then create a very simple minded service which on start/refresh installs a name service configuration specified by the service's properties, and then let NWAM apply Enhanced SMF Profiles when it switches locations. Nico -- From sacadmin Wed Mar 18 18:57:03 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2J1v2ln023783 for ; Wed, 18 Mar 2009 18:57:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n2J1uvPs005216 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Thu, 19 Mar 2009 09:57:01 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGQ00G0HDEYK000@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 18 Mar 2009 19:56:58 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGQ00LUZDEXW3B0@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 18 Mar 2009 19:56:57 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2J1uvRP027057 for ; Thu, 19 Mar 2009 01:56:57 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGQ00500DBCS900@mail-amer.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 18 Mar 2009 19:56:57 -0600 (MDT) Received: from aarti-pais-macbook-pro.local ([unknown] [129.150.17.19]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGQ00HT2DEXVIB0@mail-amer.sun.com>; Wed, 18 Mar 2009 19:56:57 -0600 (MDT) Date: Wed, 18 Mar 2009 18:56:58 -0700 From: Aarti Pai Subject: Commitment materials /PSARC/2008/532 NWAM Phase 1 Sender: Aarti.Pai@sun.com To: psarc@sun.com Cc: Renee Danson Message-id: <49C1A66A.70301@Sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 271 /shared/sac/Archives/CaseLog/arc/PSARC/2008/532 sac% ls -l commitment.materials total 77 -r--r--r-- 1 apai sac 34621 Mar 17 17:28 20qs dr-xr-sr-x 2 apai sac 8 Mar 18 15:34 manpages dr-xr-sr-x 2 apai sac 14 Mar 18 15:32 spec From Sebastien.Roy@sun.com Mon Feb 1 09:02:37 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11H2bMT025498 for ; Mon, 1 Feb 2010 09:02:37 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o11H2ZYi025779 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 1 Feb 2010 11:02:37 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX600A03A0CKL00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 09:02:36 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX6005UZA0BK120@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 09:02:35 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o11H2ZIh016339 for ; Mon, 01 Feb 2010 17:02:35 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX600G009Y9M200@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 10:02:35 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX600I4QA0AS4D0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 10:02:34 -0700 (MST) Date: Mon, 01 Feb 2010 11:59:56 -0500 From: Sebastien Roy Subject: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 Sender: Sebastien.Roy@sun.com To: psarc-ext@sun.com Message-id: <4B67088C.7030400@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_lLsHK+t/mhJZ9mPIK29JYQ)" X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 8630 This is a multi-part message in MIME format. --Boundary_(ID_lLsHK+t/mhJZ9mPIK29JYQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT For PSARC review: Attached (and also in the case directory as opinion.txt) is the opinion for PSARC/2008/532 NWAM Phase 1. The review timer is set for 02/08/2010. -Seb --Boundary_(ID_lLsHK+t/mhJZ9mPIK29JYQ) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: NWAM Phase 1 Submitted by: Renee Danson File: PSARC/2008/532/opinion.ms Date: March 25th, 2009 Committee: James D. Carlson, Mark Carlson, Richard Matthews, Sebastien Roy, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary The Network Automagic (NWAM) Phase 1 project is the second phase of NWAM. It completely replaces the earlier "Network Auto-Magic (NWAM)" (PSARC 2007/132), "NWAM Phase 0.5 (picea)" (PSARC 2008/482), and "NWAM Picea Addenda" (PSARC 2008/736) functionality with a new design and more flexible networking options. 2. Decision & Precedence Information The project is approved as specified in references [1] through [3]. The project may be delivered in a Minor release of Solaris and OpenSolaris, via the ON and GNOME consolidations. 3. Interfaces The project exports the following interfaces. ________________________________________________________________________________ | Interfaces Exported | |________________________________|_______________________|_____________________| |Interface | Classification | Comments | |________________________________|_______________________|_____________________| |/usr/sbin/nwamadm | Committed | | |/usr/sbin/nwamcfg | Committed | | |netadm | Consolidation Private| reserved UID | |netadm | Consolidation Private| reserved GID | |nwamd | Project Private | | |________________________________|_______________________|_____________________| PSARC/2008/532 Copyright 2009 Sun Microsystems - 2 - ________________________________________________________________________________ | Interfaces Exported | |________________________________|_______________________|_____________________| |Interface | Classification | Comments | |________________________________|_______________________|_____________________| |netcfgd | Project Private | Config repo daemon | |netcfg | Consolidation Private| reserved UID | |/lib/svc/method/net-ipqos | Project Private | | |/lib/svc/method/net-loc | Project Private | | |/lib/svc/method/net-netmask | Project Private | | |network/network-ipqos.xml | Project Private | SMF manifest | |network/network-location.xml | Project Private | SMF manifest | |network/network-netcfg.xml | Project Private | SMF manifest | |network/network-netmask.xml | Project Private | SMF manifest | |/usr/bin/nwam-manager-properties| | | |solaris.network.autoconf.read | Committed | Authorization | |solaris.network.autoconf.write | Committed | Authorization | |solaris.network.autoconf.refresh| Committed | Authorization | |/etc/svc/volatile/nwam | Project Private | volatile directory | | nwam/nwam_door | Project Private | door file | | nwam/nwam_backend_door | Project Private | | | nwam/nwam_event_msgs. | Project Private | message queue file | | nwam/Legacy | Project Private | Saved Location Data| | nwam/create_loc_legacy | Project Private | private script | |libnwam.so.1 | Contr. Cons. Priv. | Library ON/GNOME | |libnwam.h | Contr. Cons. Priv. | Header ON/GNOME | |libinetcfg.so.1 | Cons. Priv. | New interfaces | |/etc/nwam/enm.conf | Project Private | profile repository | |/etc/nwam/known_wlan.conf | Project Private | | |/etc/nwam/loc.conf | Project Private | | |/etc/nwam/ncp-.conf | Project Private | | |svc:/network/ipqos | Cons. Priv. | | |svc:/network/location | Cons. Priv. | | |svc:/network/netmask | Cons. Priv. | | |svc:/network/netcfg | Cons. Priv. | | |svc:/network/service | Obsolete | remove in future | |Automatic | Committed | Built-in location | |NoNet | Committed | Built-in location | |Legacy | Committed | Built-in location | |________________________________|_______________________|_____________________| The project imports the following interfaces. _________________________________________________________ | Interfaces Imported | |_____________|________________|________________________| |Interface | Classification| Comments | |_____________|________________|________________________| |/etc/nwam/llp| Obsolete | Handled during upgrade| |_____________|________________|________________________| PSARC/2008/532 Copyright 2009 Sun Microsystems - 3 - 4. Opinion 5. Futures A substantial amount of the discussion centered on issues that the project team considers to be items for future work, including servers, automated installers, VLANs, and NTP. The project team explained that there are still more phases coming, and that this one, like the previous phase, addresses lower-end users, so these concerns are out of scope for this project. The ARC members agreed with this explanation. An important distinction to note is that the Nevada instal- lation (including Jumpstart) does not enable NWAM by default. The only installer that enables it by default is the new OpenSolaris Caiman. 5.1. VNIC Problems An ARC member noted that with the existing NWAM Phase 0, VNICs are not brought online at boot time. While the users for which this project is designed may not have a need for these more advanced features, it would be desirable to have the features not be in direct conflict with each other. The discussion of this issue led to the technical change advised, described below. 5.1.1. Auditing The project team was reminded that they should coordinate with the Solaris Audit project team to make sure that the newest requirements are met. 6. Minority Opinion(s) None 7. Advisory Information None 8. Appendices 8.1. Appendix A: Technical Changes Required None 8.2. Appendix B: Technical Changes Advised 1. NWAM should be able to coexist with VNICs. It need not configure them in this phase of the PSARC/2008/532 Copyright 2009 Sun Microsystems - 4 - project, but it should not prevent them from being used on the system by manual configuration. 8.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2008/532. 1. Architecture and Design Specification File: commitment.materials/spec/index.html 2. PSARC Questionnaire File: commitment.materials/20qs 3. Draft Man Pages File: commitment.materials/manpages/ PSARC/2008/532 Copyright 2009 Sun Microsystems --Boundary_(ID_lLsHK+t/mhJZ9mPIK29JYQ)-- From John.Fischer@sun.com Mon Feb 1 09:31:22 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11HVL7g025686 for ; Mon, 1 Feb 2010 09:31:21 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o11HVKER017585 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 1 Feb 2010 11:31:21 -0600 (CST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX600M7LBC8S700@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 10:31:20 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX60095QBC5WEB0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 10:31:17 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o11HVHTx016337 for ; Mon, 01 Feb 2010 17:31:17 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX6006009NENE00@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 10:31:17 -0700 (MST) Received: from [192.168.10.7] ([unknown] [76.20.56.122]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX60096OBC1S880@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 10:31:14 -0700 (MST) Date: Mon, 01 Feb 2010 09:30:56 -0800 From: John Fischer Subject: Re: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 In-reply-to: <4B67088C.7030400@sun.com> Sender: John.Fischer@sun.com To: Sebastien Roy Cc: psarc-ext@sun.com Reply-to: John.Fischer@sun.com Message-id: <4B670FD0.3080904@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B67088C.7030400@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 750 Sebastien, The committee should list you first since you wrote the opinion. Secondly, I do not see how section 5.1 and 5.1.1 are related. It seems to me that section 5.1.1 is actually another topic all together and should be a 5.2. Finally, the current section 5.1.1 should probably generate an Advisory Information subsection. Thanks, John Sebastien Roy wrote: > For PSARC review: Attached (and also in the case directory as > opinion.txt) is the opinion for PSARC/2008/532 NWAM Phase 1. The review > timer is set for 02/08/2010. > > -Seb > > > ------------------------------------------------------------------------ > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From Nicolas.Williams@sun.com Mon Feb 1 10:02:55 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11I2svA026245 for ; Mon, 1 Feb 2010 10:02:55 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o11I2rR3014885; Mon, 1 Feb 2010 11:02:54 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX600L05CSTXK00@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Feb 2010 10:02:53 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX600FZ9CSSR960@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Feb 2010 10:02:53 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o11I2nfG021306; Mon, 01 Feb 2010 12:02:49 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o11I2neK021305; Mon, 01 Feb 2010 12:02:49 -0600 (CST) Date: Mon, 01 Feb 2010 12:02:49 -0600 From: Nicolas Williams Subject: Re: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 In-reply-to: <4B67088C.7030400@sun.com> To: Sebastien Roy Cc: psarc-ext@sun.com Message-id: <20100201180248.GO1061@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4B67088C.7030400@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2670 On Mon, Feb 01, 2010 at 11:59:56AM -0500, Sebastien Roy wrote: > 4. Opinion > No opinion? > 5. Futures > > A substantial amount of the discussion centered on issues > that the project team considers to be items for future work, > including servers, automated installers, VLANs, and NTP. > The project team explained that there are still more phases > coming, and that this one, like the previous phase, > addresses lower-end users, so these concerns are out of > scope for this project. The ARC members agreed with this > explanation. > > An important distinction to note is that the Nevada instal- > lation (including Jumpstart) does not enable NWAM by > default. The only installer that enables it by default is > the new OpenSolaris Caiman. Er, "Nevada installation", "JumpStart"? Isn't Nevada (SXCE/SXDE and builds between releases thereof) dead? There's only the OpenSolaris installer and AI to consider. Presumably AI does not enable NWAM by default, while the OpenSolaris installer does. > 5.1. VNIC Problems > > An ARC member noted that with the existing NWAM Phase 0, > VNICs are not brought online at boot time. While the users > for which this project is designed may not have a need for > these more advanced features, it would be desirable to have > the features not be in direct conflict with each other. The > discussion of this issue led to the technical change > advised, described below. Not the right place, I know, but ISTM that there are two kinds of VNICs as far as NWAM should be concerned: those that should always be brought online (and be usable via NWAM as any other interface), and those that should be brought online only for specific location profiles. (A third category: VNICs that should only be manually brought online and which should be ignored by NWAM at all times.) > 8.2. Appendix B: Technical Changes Advised > > 1. NWAM should be able to coexist with VNICs. It > need not configure them in this phase of the > project, but it should not prevent them from being > used on the system by manual configuration. The first part of this TCA sounds rather ambiguous. What does "coexist" imply in this context? The second part of this TCA sounds like a TCR to me -- it should be a TCR, at any rate. That is: nothing in this or any phase of NWAM should "prevent [VNICs] from being used on the system by manual configuration", but it should be OK for this phase of NWAM to do nothing more about VNICs. The TCA should cover the desire that NWAM actually do more about VNICs than merely ignore them. No? Nico -- From glenn.skinner@covad.net Mon Feb 1 10:10:16 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11IAFoi026285 for ; Mon, 1 Feb 2010 10:10:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o11IACsn016549; Mon, 1 Feb 2010 12:10:14 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX600M0XD51BR00@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Feb 2010 10:10:13 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX600FE7D51R4A0@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Feb 2010 10:10:13 -0800 (PST) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o11HxI6B021910; Mon, 01 Feb 2010 18:10:12 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay42i.sun.com with ESMTP id BT-MMP-7066; Mon, 01 Feb 2010 18:10:12 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-25942889; Mon, 01 Feb 2010 18:10:12 +0000 (Z) Received: from mail156c8.megamailservers.com ([209.235.129.66] [209.235.129.66]) by relay4i.sun.com with ESMTP id BT-MMP-397372; Mon, 01 Feb 2010 18:10:12 +0000 (Z) Received: from [192.168.1.106] (h-64-105-36-23.snvacaid.static.covad.net [64.105.36.23]) by mail156c8.megamailservers.com (8.13.6/8.13.1) with ESMTP id o11IA9BK020969; Mon, 01 Feb 2010 13:10:11 -0500 Date: Mon, 01 Feb 2010 10:10:09 -0800 From: Glenn Skinner Subject: Re: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 In-reply-to: <4B670FD0.3080904@sun.com> To: John.Fischer@sun.com Cc: Sebastien Roy , psarc-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-POP-User: dbclispr@covad.net X-Antispam: No, score=3.2/5.0, scanned in 0.204sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B67088C.7030400@sun.com> <4B670FD0.3080904@sun.com> Status: RO Content-Length: 710 On Feb 1, 2010, at 9:30 AM, John Fischer wrote: > Sebastien, > > The committee should list you first since you wrote the opinion. > Secondly, I do not see how section 5.1 and 5.1.1 are related. It > seems to me that section 5.1.1 is actually another topic all together > and should be a 5.2. Finally, the current section 5.1.1 should > probably > generate an Advisory Information subsection. To follow up on John's comment, it seems to me that, in the [nt]roff source, some arguments to macro calls for section transitions didn't specify the proper depth. If sections were to be renumbered as follows, things would make more sense. is should be 5 4.1 5.1 4.2 5.1.1 4.3 6 5 and so on -- Glenn From Alan.Coopersmith@sun.com Mon Feb 1 11:00:11 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11J0A30027327 for ; Mon, 1 Feb 2010 11:00:10 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o11J07fY062437 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 1 Feb 2010 12:00:10 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX60082HFG9FV00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 12:00:09 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX6005TQFG69610@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 12:00:06 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o11J058n003819 for ; Mon, 01 Feb 2010 11:00:05 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX600600F0LUS00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 11:00:05 -0800 (PST) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX6007EQFFC7HF0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 10:59:36 -0800 (PST) Date: Mon, 01 Feb 2010 10:59:36 -0800 From: Alan Coopersmith Subject: Re: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 In-reply-to: <20100201180248.GO1061@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Nicolas Williams Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <4B672498.3070601@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4B67088C.7030400@sun.com> <20100201180248.GO1061@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 1218 Nicolas Williams wrote: >> 5. Futures >> >> A substantial amount of the discussion centered on issues >> that the project team considers to be items for future work, >> including servers, automated installers, VLANs, and NTP. >> The project team explained that there are still more phases >> coming, and that this one, like the previous phase, >> addresses lower-end users, so these concerns are out of >> scope for this project. The ARC members agreed with this >> explanation. >> >> An important distinction to note is that the Nevada instal- >> lation (including Jumpstart) does not enable NWAM by >> default. The only installer that enables it by default is >> the new OpenSolaris Caiman. > > Er, "Nevada installation", "JumpStart"? Isn't Nevada (SXCE/SXDE and > builds between releases thereof) dead? Nevada is the code name for the development branch of Solaris. It is alive and well - it's just the SVR4 packaged version of it (SXCE), and the related installers that are dead. Nevada builds 131 and later are only being made in IPS packaged versions. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From nicolas.williams@sun.com Mon Feb 1 11:06:01 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11J60WV027398 for ; Mon, 1 Feb 2010 11:06:01 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o11J5tcZ002203; Mon, 1 Feb 2010 12:05:59 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX600227FPY1V00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Feb 2010 11:05:58 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX6005ZDFPYJRB0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Feb 2010 11:05:58 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o11J5vRR021359; Mon, 01 Feb 2010 13:05:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o11J5vof021358; Mon, 01 Feb 2010 13:05:57 -0600 (CST) Date: Mon, 01 Feb 2010 13:05:57 -0600 From: Nicolas Williams Subject: Re: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 In-reply-to: <4B672498.3070601@sun.com> To: Alan Coopersmith Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <20100201190557.GQ1061@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4B67088C.7030400@sun.com> <20100201180248.GO1061@Sun.COM> <4B672498.3070601@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1616 On Mon, Feb 01, 2010 at 10:59:36AM -0800, Alan Coopersmith wrote: > Nicolas Williams wrote: > >> 5. Futures > >> > >> A substantial amount of the discussion centered on issues > >> that the project team considers to be items for future work, > >> including servers, automated installers, VLANs, and NTP. > >> The project team explained that there are still more phases > >> coming, and that this one, like the previous phase, > >> addresses lower-end users, so these concerns are out of > >> scope for this project. The ARC members agreed with this > >> explanation. > >> > >> An important distinction to note is that the Nevada instal- > >> lation (including Jumpstart) does not enable NWAM by > >> default. The only installer that enables it by default is > >> the new OpenSolaris Caiman. > > > > Er, "Nevada installation", "JumpStart"? Isn't Nevada (SXCE/SXDE and > > builds between releases thereof) dead? > > Nevada is the code name for the development branch of Solaris. > It is alive and well - it's just the SVR4 packaged version of > it (SXCE), and the related installers that are dead. Nevada > builds 131 and later are only being made in IPS packaged versions. But I didn't take issue with "Nevada". I took issue with "Nevada installation" and "JumpStart". The former strikes me as a reference to the installer used in SXCE. The latter is certainly a reference to a pre-IPS/OpenSolaris installer that is now obsolete. The "important distinction to note" here is whether the post-IPS, post-build 131 OpenSolaris installers enable NWAM by default. Nico -- From carlsonj@workingcode.com Mon Feb 1 11:39:09 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11Jd9ec027923 for ; Mon, 1 Feb 2010 11:39:09 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o11Jd83I026758; Mon, 1 Feb 2010 11:39:08 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX600C05H98CG00@brm-avmta-1.central.sun.com>; Mon, 01 Feb 2010 12:39:08 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX6005QGH979G30@brm-avmta-1.central.sun.com>; Mon, 01 Feb 2010 12:39:07 -0700 (MST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o11JOSQt026931; Mon, 01 Feb 2010 19:39:07 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-373021; Mon, 01 Feb 2010 19:38:55 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-32672408; Mon, 01 Feb 2010 19:38:54 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-5884576; Mon, 01 Feb 2010 19:38:54 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o11Jcnb2003234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Feb 2010 14:38:53 -0500 (EST) Date: Mon, 01 Feb 2010 14:38:49 -0500 From: James Carlson Subject: Re: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 In-reply-to: <20100201190557.GQ1061@Sun.COM> To: Nicolas Williams Cc: PSARC-ext@sun.com Message-id: <4B672DC9.1020004@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=3.2/5.0, scanned in 0.195sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B67088C.7030400@sun.com> <20100201180248.GO1061@Sun.COM> <4B672498.3070601@sun.com> <20100201190557.GQ1061@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 616 Nicolas Williams wrote: > But I didn't take issue with "Nevada". I took issue with "Nevada > installation" and "JumpStart". The former strikes me as a reference to > the installer used in SXCE. The latter is certainly a reference to a > pre-IPS/OpenSolaris installer that is now obsolete. > > The "important distinction to note" here is whether the post-IPS, > post-build 131 OpenSolaris installers enable NWAM by default. You might want to check the date when the review itself was held. This wasn't a recent project by any means. -- James Carlson 42.703N 71.076W From Sebastien.Roy@sun.com Mon Feb 1 11:51:14 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11JpEoL028013 for ; Mon, 1 Feb 2010 11:51:14 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o11JpBHK041151 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 1 Feb 2010 12:51:14 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX600703HTDLW00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 11:51:13 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX60055EHTAJYE0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 11:51:11 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o11JpAdu022003 for ; Mon, 01 Feb 2010 19:51:10 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX600B00HPQ9P00@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 12:51:10 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX600LELHSNAVD0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 01 Feb 2010 12:50:48 -0700 (MST) Date: Mon, 01 Feb 2010 14:48:11 -0500 From: Sebastien Roy Subject: Re: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 In-reply-to: <4B670FD0.3080904@sun.com> Sender: Sebastien.Roy@sun.com To: John.Fischer@sun.com Cc: PSARC-ext@sun.com Message-id: <4B672FFB.9030303@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B67088C.7030400@sun.com> <4B670FD0.3080904@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 811 On 02/ 1/10 12:30 PM, John Fischer wrote: > Sebastien, > > The committee should list you first since you wrote the opinion. Sort of, Jim Carlson wrote the opinion (he was the case owner). The project team came to me asking to make progress on the case status before they integrate, and so I took Jim's opinion and touched up a few details in order to move forward with it. I suppose if it matters, I can move my name to the front... > Secondly, I do not see how section 5.1 and 5.1.1 are related. It > seems to me that section 5.1.1 is actually another topic all together > and should be a 5.2. Finally, the current section 5.1.1 should probably > generate an Advisory Information subsection. I fixed the section numbering, there were a couple of bogus ".NH" macros in the nroff source. Thanks, -Seb From Sebastien.Roy@sun.com Mon Feb 1 12:08:06 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11K852A028501 for ; Mon, 1 Feb 2010 12:08:06 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o11K6Z41007112 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 1 Feb 2010 14:08:05 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX600901IL8MD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 12:07:56 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX60053QIL7JRF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 12:07:55 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o11K7tml003189 for ; Mon, 01 Feb 2010 20:07:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX600300I90SE00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 13:07:55 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX600DCKIL6IO00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 13:07:55 -0700 (MST) Date: Mon, 01 Feb 2010 15:05:19 -0500 From: Sebastien Roy Subject: Re: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 In-reply-to: <20100201180248.GO1061@Sun.COM> Sender: Sebastien.Roy@sun.com To: Nicolas Williams Cc: PSARC-ext@sun.com Message-id: <4B6733FF.8090307@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B67088C.7030400@sun.com> <20100201180248.GO1061@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 4066 Nicolas, On 02/ 1/10 01:02 PM, Nicolas Williams wrote: > On Mon, Feb 01, 2010 at 11:59:56AM -0500, Sebastien Roy wrote: >> 4. Opinion >> > > No opinion? Yes, it's contained in the three subsequent sections that had incorrect numbering. I've just fixed the numbering. > >> 5. Futures >> >> A substantial amount of the discussion centered on issues >> that the project team considers to be items for future work, >> including servers, automated installers, VLANs, and NTP. >> The project team explained that there are still more phases >> coming, and that this one, like the previous phase, >> addresses lower-end users, so these concerns are out of >> scope for this project. The ARC members agreed with this >> explanation. >> >> An important distinction to note is that the Nevada instal- >> lation (including Jumpstart) does not enable NWAM by >> default. The only installer that enables it by default is >> the new OpenSolaris Caiman. > > Er, "Nevada installation", "JumpStart"? Isn't Nevada (SXCE/SXDE and > builds between releases thereof) dead? > > There's only the OpenSolaris installer and AI to consider. Presumably > AI does not enable NWAM by default, while the OpenSolaris installer > does. I think the opinion is still valid given the context in which the review happened. The bigger point is that NWAM was only enabled by default on the OpenSolaris releases, and the philosophy behind that was that NWAM isn't ready for the enterprise and more complex networking features. That's still true today; NWAM isn't any more ready for the enterprise, and the project management teams of networking and install need to think about how this is going to be handled. AFAIK, this is in fact being talked about. > >> 5.1. VNIC Problems >> >> An ARC member noted that with the existing NWAM Phase 0, >> VNICs are not brought online at boot time. While the users >> for which this project is designed may not have a need for >> these more advanced features, it would be desirable to have >> the features not be in direct conflict with each other. The >> discussion of this issue led to the technical change >> advised, described below. > > Not the right place, I know, but ISTM that there are two kinds of VNICs > as far as NWAM should be concerned: those that should always be brought > online (and be usable via NWAM as any other interface), and those that > should be brought online only for specific location profiles. (A third > category: VNICs that should only be manually brought online and which > should be ignored by NWAM at all times.) Okay, I think this would be a good discussion for nwam-discuss@opensolaris.org. > >> 8.2. Appendix B: Technical Changes Advised >> >> 1. NWAM should be able to coexist with VNICs. It >> need not configure them in this phase of the >> project, but it should not prevent them from being >> used on the system by manual configuration. > > The first part of this TCA sounds rather ambiguous. What does "coexist" > imply in this context? It means that VNICs should be brought online at boot time. > > The second part of this TCA sounds like a TCR to me -- it should be a > TCR, at any rate. That is: nothing in this or any phase of NWAM should > "prevent [VNICs] from being used on the system by manual configuration", > but it should be OK for this phase of NWAM to do nothing more about > VNICs. The TCA should cover the desire that NWAM actually do more about > VNICs than merely ignore them. No? The opinion is meant to summarize what was voted on at the time of the review (the review happened in March of 2009). Going back and changing the requirements imposed by the ARC isn't really in scope of the opinion review. In this case, however, I don't think it really matters whether this is a TCA or a TCR. The project team is doing the right thing and bringing up VNICs at boot time (if this were a TCR, they'd adhere to it anyway), but ignoring them as datalinks. -Seb From Sebastien.Roy@sun.com Mon Feb 1 12:17:36 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o11KHZgn028587 for ; Mon, 1 Feb 2010 12:17:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o11KHXI6060228 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 1 Feb 2010 13:17:35 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX600601J1A3700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 12:17:34 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX600573J1ALM10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 12:17:34 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o11KHYAD020159 for ; Mon, 01 Feb 2010 20:17:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX600G00IO0KF00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 13:17:34 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX600DNIJ19IO30@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Feb 2010 13:17:33 -0700 (MST) Date: Mon, 01 Feb 2010 15:14:57 -0500 From: Sebastien Roy Subject: Re: Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1 In-reply-to: <20100201190557.GQ1061@Sun.COM> Sender: Sebastien.Roy@sun.com To: Nicolas Williams Cc: Alan Coopersmith , PSARC-ext@sun.com Message-id: <4B673641.1030800@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B67088C.7030400@sun.com> <20100201180248.GO1061@Sun.COM> <4B672498.3070601@sun.com> <20100201190557.GQ1061@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 1030 On 02/ 1/10 02:05 PM, Nicolas Williams wrote: > On Mon, Feb 01, 2010 at 10:59:36AM -0800, Alan Coopersmith wrote: >> Nevada is the code name for the development branch of Solaris. >> It is alive and well - it's just the SVR4 packaged version of >> it (SXCE), and the related installers that are dead. Nevada >> builds 131 and later are only being made in IPS packaged versions. > > But I didn't take issue with "Nevada". I took issue with "Nevada > installation" and "JumpStart". The former strikes me as a reference to > the installer used in SXCE. The latter is certainly a reference to a > pre-IPS/OpenSolaris installer that is now obsolete. > > The "important distinction to note" here is whether the post-IPS, > post-build 131 OpenSolaris installers enable NWAM by default. I agree, and both the NWAM and Install teams are working this out. I don't know what form the solution will take as it relates to architecture review, but I would hope that the solution will make its way to this committee in due time. -Seb