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