From sacadmin Wed Sep 14 10:23:27 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j8EHNREu018596 for ; Wed, 14 Sep 2005 10:23:27 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j8EHNLn04863; Wed, 14 Sep 2005 11:23:21 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j8EHNKf8001720; Wed, 14 Sep 2005 10:23:20 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j8EHNKEu018591; Wed, 14 Sep 2005 10:23:20 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id j8EHNKlg018590; Wed, 14 Sep 2005 10:23:20 -0700 (PDT) Date: Wed, 14 Sep 2005 10:23:20 -0700 (PDT) Message-Id: <200509141723.j8EHNKlg018590@sac.sfbay.sun.com> To: PSARC@sun.com Cc: James.D.Carlson@sun.com, PSARC-coord@sun.com From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/474 Zones Upgrade (Ashanti and Zulu) Content-type: text/plain Status: RO Content-Length: 508 New Materials submitted for PSARC 2005/474 Zones Upgrade (Ashanti and Zulu) Status: inception scheduled 09/21/2005 Files: /shared/sac/PSARC/2005/474/inception.materials/20questions.txt /shared/sac/PSARC/2005/474/inception.materials/interimUpdateDesign.txt /shared/sac/PSARC/2005/474/inception.materials/jumpstart.txt /shared/sac/PSARC/2005/474/inception.materials/scratchzone-design.pdf /shared/sac/PSARC/2005/474/inception.materials/upgradezone-3.3.pdf Please let me know if you have questions. - PSARC From sacadmin Wed Oct 12 12:31:38 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j9CJVcEu026985 for ; Wed, 12 Oct 2005 12:31:38 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j9CJVcpN020784; Wed, 12 Oct 2005 15:31:38 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j9CJVcJq020781; Wed, 12 Oct 2005 15:31:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17229.25754.105174.496263@gargle.gargle.HOWL> Date: Wed, 12 Oct 2005 15:31:38 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Zones Upgrade I-Team Subject: 2005/474 Zones Upgrade (Ashanti and Zulu): updated interface table X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 916 I've placed updated interfaces (all exports) for this project in final.materials. Please review. There are two draft contracts here that will need to be negotiated and signed. One is for the NFS hack we're using (documented in section 5.2 of inception.materials/scratchzone-design.pdf), and the other is for the updated libzonecfg interfaces (amending the contract from 2003/460). There is also a very rough draft of the change in rules for patch scripts imposed by Ashanti's use of patches during upgrade of Zones and diskless client roots. This part is undergoing change as we speak, but general idea (that there will be a change required in compliant patch scripts) will remain true. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Fri Oct 28 18:26:19 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j9T1QJIQ013620 for ; Fri, 28 Oct 2005 18:26:19 -0700 (PDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IP300901L5Y4L@mpk-mail1.sfbay.sun.com> (original mail from Victor.Nelson@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 28 Oct 2005 18:26:19 -0700 (PDT) Received: from Sun.COM (sr1-umpk-11.SFBay.Sun.COM [129.146.11.181]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IP300M5ALBUIU@mpk-mail1.sfbay.sun.com>; Fri, 28 Oct 2005 18:26:19 -0700 (PDT) Date: Fri, 28 Oct 2005 18:26:18 -0700 From: Victor Nelson Subject: Re: contract-01 for 2005/474 (Zones Upgrade NFS work-around) In-reply-to: <17250.23743.322839.788043@gargle.gargle.HOWL> To: psarc@sac.sfbay.sun.com Cc: Lisa.Chatham@Sun.COM, Jim Carlson Reply-to: Victor.Nelson@Sun.COM Message-id: <4362CFBA.1050106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <17250.23743.322839.788043@gargle.gargle.HOWL> Status: RO Content-Length: 4734 I agree. Victor James Carlson wrote On 10/28/05 10:15,: > I've copied below the contract we need for the temporary cross-zone > traffic work-around used by Ashanti (the S10U1 Zones Upgrade > solution). I've been in contact with Robert Thurlow throughout the > design and implementation of this change, so I expect we have good > technical agreement. > > In short, this contract places all of the burden on the Zones Upgrade > team. We'll maintain it as necessary, and plan to rip it back out as > soon as it's no longer needed (currently projected to be S10U3). > > Please review the contract. If you agree to the terms, reply to > psarc@sac.sfbay and say that you agree (the Reply-to address is set on > this message, so just replying should work). If you don't agree, then > let me know, and we'll work out alternatives for any problematic > text. (No need to copy the ARC on that; we should work this off-line > and just provide the summary to the ARC.) > > There's no specific time pressure to get this done, but it'd be > helpful to me to have it within a week so that I can move the ARC > opinion review forward. > > Thanks! > > > > @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2005/474/01 > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Product or Bundle: Solaris > Consolidation: ON > Department or Group: NFS > Bugtraq Category/SubCategory: kernel/nfs > Responsible Manager: lisa.chatham@sun.com > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: Admin/Install > Department or Group: Install > Bugtraq Category/SubCategory: sysadmin/pkg_commands > Responsible Manager: victor.nelson@sun.com > > 4. The INTERFACES are: > > nfs_global_client_only Consolidation Private > > 5. The ARC controlling these INTERFACES is: > PSARC > > 6. The CASE describing these INTERFACES is: > 2005/474 > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will > import INTERFACES from a separate consolidation. > > Consumer will supply implementation, testing, and maintenance > of feature. > > Feature will be removed upon removal of Ashanti upgrade solution, > expected to be on or before Solaris 10 Update 3. > > 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make > best effort to accommodate such changes, which shall then be > treated in accordance with paragraph 7 above. > > 9. Notwithstanding paragraphs 7 and 8, a change to any portion > of the INTERFACES shall be regarded as a completely new set of > INTERFACES which require both ARC approval and execution of > a new contract. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > > Will not evolve. Will be removed. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > Consumer agrees to provide all support necessary for this > interface. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > No documentation other than comments in source code. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > Consumer will perform NFS regression testing and all functional > testing as required for Ashanti. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > Will be terminated on removal of Ashanti, or earlier by > mutual agreement. > > 15. This contract is not valid until "signed" via agreement from the > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > this contract. E-mail agreement to the contract should be archived > in the mail archive of CASE; verbal agreement to the contract > should be noted in the meeting minutes. This contract remains > valid until superseded or invalidated. > > For SUPPLIER: Date: > For CONSUMER: Date: > For ARC: Date: > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: From sacadmin Fri Oct 28 18:27:00 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j9T1R0IQ013633 for ; Fri, 28 Oct 2005 18:27:00 -0700 (PDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IP300901L5Y4L@mpk-mail1.sfbay.sun.com> (original mail from Victor.Nelson@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 28 Oct 2005 18:27:00 -0700 (PDT) Received: from Sun.COM (sr1-umpk-11.SFBay.Sun.COM [129.146.11.181]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IP300M72LD0IU@mpk-mail1.sfbay.sun.com>; Fri, 28 Oct 2005 18:27:00 -0700 (PDT) Date: Fri, 28 Oct 2005 18:26:59 -0700 From: Victor Nelson Subject: Re: contract-02 for 2005/474 (Zones Upgrade private features) In-reply-to: <17250.24061.891166.459546@gargle.gargle.HOWL> To: psarc@sac.sfbay.sun.com Cc: Allan.McKillop@Sun.COM, Jim Carlson Reply-to: Victor.Nelson@Sun.COM Message-id: <4362CFE3.4000506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <17250.24061.891166.459546@gargle.gargle.HOWL> Status: RO Content-Length: 6987 I agree. Victor James Carlson wrote On 10/28/05 10:21,: > I've copied below the contract we need for the private Zones command > features and "Scratch Zone" support to be used by Ashanti (the S10U1 > Zones Upgrade solution) and Zulu (the permanent Live Upgrade > solution). I've been in contact with David Comay throughout the > design and implementation of this change, so I expect we have good > technical agreement. > > In short, this contract places most of the support burden on the Zones > Upgrade team, at least until these interfaces become publicly > documented. (I expect that at some point in the near future, we will > need to expose all of these mechanisms to customers so that they can > build their own administrative tools. There are some architectural > issues with Live Upgrade, though, that likely need to be worked out > first.) > > Please review the contract. If you agree to the terms, reply to > psarc@sac.sfbay and say that you agree (the Reply-to address is set on > this message, so just replying should work). If you don't agree, then > let me know, and we'll work out alternatives for any problematic > text. (No need to copy the ARC on that; we should work this off-line > and just provide the summary to the ARC.) > > There's no specific time pressure to get this done, but it'd be > helpful to me to have it within a week so that I can move the ARC > opinion review forward. > > Thanks! > > > > @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2005/474-02 > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Product or Bundle: Solaris > Consolidation: ON > Department or Group: Zones > Bugtraq Category/SubCategory: utility/zones > Responsible Manager: allan.mckillop@sun.com > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: Admin/Install > Department or Group: Install > Bugtraq Category/SubCategory: sysadmin/pkg_commands > Responsible Manager: victor.nelson@sun.com > > 4. The INTERFACES are: > > In libzonecfg: > > zonecfg_set_root Project Private > zonecfg_get_root Project Private > zonecfg_in_alt_root Project Private > zonecfg_get_name_by_uuid Project Private > zonecfg_get_uuid Project Private > zonecfg_open_scratch Project Private > zonecfg_lock_scratch Project Private > zonecfg_close_scratch Project Private > zonecfg_get_scratch Project Private > zonecfg_find_scratch Project Private > zonecfg_reverse_scratch Project Private > zonecfg_add_scratch Project Private > zonecfg_delete_scratch Project Private > zonecfg_is_scratch Project Private > > "zlogin -R" Project Private > "zoneadm -R" Project Private > "zoneadm mount" Project Private > "zoneadm unmount" Project Private > > 5. The ARC controlling these INTERFACES is: > PSARC > > 6. The CASE describing these INTERFACES is: > 2005/474 > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _Y_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > In a patch or micro release with prior agreement of consumer. > > In a minor release. > > _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will > import INTERFACES from a separate consolidation. > > _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any > portion of the INTERFACES, SUPPLIER will notify CONSUMER of the > proposed new version, no later than the application for ARC > approval of the new version. > If SUPPLIER and CONSUMER are contained in the same consolidation, > they have the option of arranging for simultaneous conversion > to the new interfaces. If this is not possible, or if they are > not in the same consolidation, then SUPPLIER will either make best > effort to work with CONSUMER so that CONSUMER can detect which > version of INTERFACES is being supplied, or else SUPPLIER will > make best effort to supply both old and new versions of > INTERFACES. > If SUPPLIER cannot make both versions of INTERFACES available, > and SUPPLIER and CONSUMER cannot devise a method whereby > CONSUMER can detect which version of INTERFACES is being > supplied, and the old version of CONSUMER will not run with the > new version of SUPPLIER, then either the EOL process must be > followed by SUPPLIER, or else a major release of SUPPLIER will > be required, or the change will not be allowed. > > 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make > best effort to accommodate such changes, which shall then be > treated in accordance with paragraph 7 above. > > 9. Notwithstanding paragraphs 7 and 8, a change to any portion > of the INTERFACES shall be regarded as a completely new set of > INTERFACES which require both ARC approval and execution of > a new contract. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > > In a patch or micro release, Supplier will seek approval of > change from Consumer to provide compatibility. > > In Minor or Major release, Supplier must notify Consumer 12 > weeks prior to Beta cut-off of incompatible changes. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > Consumer will provide support for interfaces. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > No documentation other than header files, comments, and this > ARC case provided. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > Consumer will test interfaces. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > Mutual consent. > > 15. This contract is not valid until "signed" via agreement from the > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > this contract. E-mail agreement to the contract should be archived > in the mail archive of CASE; verbal agreement to the contract > should be noted in the meeting minutes. This contract remains > valid until superseded or invalidated. > > For SUPPLIER: Date: > For CONSUMER: Date: > For ARC: Date: > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > From sacadmin Tue Nov 1 06:40:11 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jA1EeBIQ008287 for ; Tue, 1 Nov 2005 06:40:11 -0800 (PST) Received: from papago (papago.SFBay.Sun.COM [129.146.58.63]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jA1Ee9aY899586; Tue, 1 Nov 2005 06:40:09 -0800 (PST) Message-Id: <200511011440.jA1Ee9aY899586@jurassic.eng.sun.com> Date: Tue, 1 Nov 2005 06:35:25 -0800 (PST) From: Lisa M Chatham Reply-To: Lisa M Chatham Subject: Re: contract-01 for 2005/474 (Zones Upgrade NFS work-around) To: psarc@sac.sfbay.sun.com, Victor.Nelson@Sun.COM Cc: Lisa.Chatham@Sun.COM, James.D.Carlson@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: syOZnHbPNGFoLNlkvVOFCQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 5378 I agree. l- >Date: Fri, 28 Oct 2005 18:26:18 -0700 >From: Victor Nelson >Subject: Re: contract-01 for 2005/474 (Zones Upgrade NFS work-around) >To: psarc@sac.sfbay.sun.com >Cc: Lisa.Chatham@Sun.COM, Jim Carlson >MIME-version: 1.0 >Content-transfer-encoding: 7BIT >X-Accept-Language: en-us, en >User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 > >I agree. > >Victor > >James Carlson wrote On 10/28/05 10:15,: >> I've copied below the contract we need for the temporary cross-zone >> traffic work-around used by Ashanti (the S10U1 Zones Upgrade >> solution). I've been in contact with Robert Thurlow throughout the >> design and implementation of this change, so I expect we have good >> technical agreement. >> >> In short, this contract places all of the burden on the Zones Upgrade >> team. We'll maintain it as necessary, and plan to rip it back out as >> soon as it's no longer needed (currently projected to be S10U3). >> >> Please review the contract. If you agree to the terms, reply to >> psarc@sac.sfbay and say that you agree (the Reply-to address is set on >> this message, so just replying should work). If you don't agree, then >> let me know, and we'll work out alternatives for any problematic >> text. (No need to copy the ARC on that; we should work this off-line >> and just provide the summary to the ARC.) >> >> There's no specific time pressure to get this done, but it'd be >> helpful to me to have it within a week so that I can move the ARC >> opinion review forward. >> >> Thanks! >> >> >> >> @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] >> >> CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES >> >> 0. Number: PSARC/2005/474/01 >> >> 1. This contract is between >> a SUPPLIER of INTERFACES and >> a CONSUMER of those INTERFACES, >> both of whom are entities within Sun Microsystems, Incorporated. >> >> 2. The SUPPLIER (definer and/or implementor) is identified by the following: >> Product or Bundle: Solaris >> Consolidation: ON >> Department or Group: NFS >> Bugtraq Category/SubCategory: kernel/nfs >> Responsible Manager: lisa.chatham@sun.com >> >> 3. The CONSUMER is identified by the following: >> Product or Bundle: Solaris >> Consolidation: Admin/Install >> Department or Group: Install >> Bugtraq Category/SubCategory: sysadmin/pkg_commands >> Responsible Manager: victor.nelson@sun.com >> >> 4. The INTERFACES are: >> >> nfs_global_client_only Consolidation Private >> >> 5. The ARC controlling these INTERFACES is: >> PSARC >> >> 6. The CASE describing these INTERFACES is: >> 2005/474 >> >> 7. The following SPECIAL ARRANGEMENTS are made which modify the rules >> imposed by the stability levels listed in section 4 above: >> >> _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will >> import INTERFACES from a separate consolidation. >> >> Consumer will supply implementation, testing, and maintenance >> of feature. >> >> Feature will be removed upon removal of Ashanti upgrade solution, >> expected to be on or before Solaris 10 Update 3. >> >> 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make >> best effort to accommodate such changes, which shall then be >> treated in accordance with paragraph 7 above. >> >> 9. Notwithstanding paragraphs 7 and 8, a change to any portion >> of the INTERFACES shall be regarded as a completely new set of >> INTERFACES which require both ARC approval and execution of >> a new contract. >> >> 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be >> handled as follows: >> >> Will not evolve. Will be removed. >> >> 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as >> follows: >> >> Consumer agrees to provide all support necessary for this >> interface. >> >> 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as >> follows: >> >> No documentation other than comments in source code. >> >> 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be >> tested as follows: >> >> Consumer will perform NFS regression testing and all functional >> testing as required for Ashanti. >> >> 14. SUPPLIER and CONSUMER agree that this contract can be terminated as >> follows: >> >> Will be terminated on removal of Ashanti, or earlier by >> mutual agreement. >> >> 15. This contract is not valid until "signed" via agreement from the >> SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by >> this contract. E-mail agreement to the contract should be archived >> in the mail archive of CASE; verbal agreement to the contract >> should be noted in the meeting minutes. This contract remains >> valid until superseded or invalidated. >> >> For SUPPLIER: Date: >> For CONSUMER: Date: >> For ARC: Date: >> >> A copy of this contract shall be deposited in the CASE directory as >> "contract-" or in a "contracts" subdirectory. >> >> 16. (Not to be filled in until superseded or invalidated.) >> This contract was superseded or invalidated by CASE: >> For ARC: Date: > Lisa Chatham, Engineering Manager Data Technology and Platform Engineering OP/N1 - RPE From sacadmin Tue Nov 8 14:48:54 2005 Received: from tanelorn.sfbay.sun.com (tanelorn.SFBay.Sun.COM [129.146.228.148]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jA8MmsIQ022665 for ; Tue, 8 Nov 2005 14:48:54 -0800 (PST) Received: from tanelorn.sfbay.sun.com (localhost [127.0.0.1]) by tanelorn.sfbay.sun.com (8.13.3+Sun/8.13.3) with ESMTP id jA8MlWVr004909; Tue, 8 Nov 2005 14:47:32 -0800 (PST) Received: (from allan@localhost) by tanelorn.sfbay.sun.com (8.13.3+Sun/8.13.3/Submit) id jA8MlWBS004908; Tue, 8 Nov 2005 14:47:32 -0800 (PST) Date: Tue, 8 Nov 2005 14:47:32 -0800 From: Allan McKillop To: psarc@sac.sfbay.sun.com Cc: Victor Nelson , Jim Carlson Subject: Re: contract-02 for 2005/474 (Zones Upgrade private features) Message-ID: <20051108224732.GA4885@eng.sun.com> Reply-To: Allan McKillop References: <17250.24061.891166.459546@gargle.gargle.HOWL> <4362CFE3.4000506@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4362CFE3.4000506@Sun.COM> User-Agent: Mutt/1.4.2.1i Organization: Solaris Kernel Development; Sun Microsystems, Inc. Status: RO Content-Length: 7344 I agree. --allan > James Carlson wrote On 10/28/05 10:21,: > > I've copied below the contract we need for the private Zones command > > features and "Scratch Zone" support to be used by Ashanti (the S10U1 > > Zones Upgrade solution) and Zulu (the permanent Live Upgrade > > solution). I've been in contact with David Comay throughout the > > design and implementation of this change, so I expect we have good > > technical agreement. > > > > In short, this contract places most of the support burden on the Zones > > Upgrade team, at least until these interfaces become publicly > > documented. (I expect that at some point in the near future, we will > > need to expose all of these mechanisms to customers so that they can > > build their own administrative tools. There are some architectural > > issues with Live Upgrade, though, that likely need to be worked out > > first.) > > > > Please review the contract. If you agree to the terms, reply to > > psarc@sac.sfbay and say that you agree (the Reply-to address is set on > > this message, so just replying should work). If you don't agree, then > > let me know, and we'll work out alternatives for any problematic > > text. (No need to copy the ARC on that; we should work this off-line > > and just provide the summary to the ARC.) > > > > There's no specific time pressure to get this done, but it'd be > > helpful to me to have it within a week so that I can move the ARC > > opinion review forward. > > > > Thanks! > > > > > > > > @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] > > > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > > > 0. Number: PSARC/2005/474-02 > > > > 1. This contract is between > > a SUPPLIER of INTERFACES and > > a CONSUMER of those INTERFACES, > > both of whom are entities within Sun Microsystems, Incorporated. > > > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > > Product or Bundle: Solaris > > Consolidation: ON > > Department or Group: Zones > > Bugtraq Category/SubCategory: utility/zones > > Responsible Manager: allan.mckillop@sun.com > > > > 3. The CONSUMER is identified by the following: > > Product or Bundle: Solaris > > Consolidation: Admin/Install > > Department or Group: Install > > Bugtraq Category/SubCategory: sysadmin/pkg_commands > > Responsible Manager: victor.nelson@sun.com > > > > 4. The INTERFACES are: > > > > In libzonecfg: > > > > zonecfg_set_root Project Private > > zonecfg_get_root Project Private > > zonecfg_in_alt_root Project Private > > zonecfg_get_name_by_uuid Project Private > > zonecfg_get_uuid Project Private > > zonecfg_open_scratch Project Private > > zonecfg_lock_scratch Project Private > > zonecfg_close_scratch Project Private > > zonecfg_get_scratch Project Private > > zonecfg_find_scratch Project Private > > zonecfg_reverse_scratch Project Private > > zonecfg_add_scratch Project Private > > zonecfg_delete_scratch Project Private > > zonecfg_is_scratch Project Private > > > > "zlogin -R" Project Private > > "zoneadm -R" Project Private > > "zoneadm mount" Project Private > > "zoneadm unmount" Project Private > > > > 5. The ARC controlling these INTERFACES is: > > PSARC > > > > 6. The CASE describing these INTERFACES is: > > 2005/474 > > > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > > imposed by the stability levels listed in section 4 above: > > > > _Y_ 7a. Although the stability level doesn't normally restrict it, > > SUPPLIER promises to only modify INTERFACES in an incompatible > > way as follows: > > > > In a patch or micro release with prior agreement of consumer. > > > > In a minor release. > > > > _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will > > import INTERFACES from a separate consolidation. > > > > _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any > > portion of the INTERFACES, SUPPLIER will notify CONSUMER of the > > proposed new version, no later than the application for ARC > > approval of the new version. > > If SUPPLIER and CONSUMER are contained in the same consolidation, > > they have the option of arranging for simultaneous conversion > > to the new interfaces. If this is not possible, or if they are > > not in the same consolidation, then SUPPLIER will either make best > > effort to work with CONSUMER so that CONSUMER can detect which > > version of INTERFACES is being supplied, or else SUPPLIER will > > make best effort to supply both old and new versions of > > INTERFACES. > > If SUPPLIER cannot make both versions of INTERFACES available, > > and SUPPLIER and CONSUMER cannot devise a method whereby > > CONSUMER can detect which version of INTERFACES is being > > supplied, and the old version of CONSUMER will not run with the > > new version of SUPPLIER, then either the EOL process must be > > followed by SUPPLIER, or else a major release of SUPPLIER will > > be required, or the change will not be allowed. > > > > 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make > > best effort to accommodate such changes, which shall then be > > treated in accordance with paragraph 7 above. > > > > 9. Notwithstanding paragraphs 7 and 8, a change to any portion > > of the INTERFACES shall be regarded as a completely new set of > > INTERFACES which require both ARC approval and execution of > > a new contract. > > > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > > handled as follows: > > > > In a patch or micro release, Supplier will seek approval of > > change from Consumer to provide compatibility. > > > > In Minor or Major release, Supplier must notify Consumer 12 > > weeks prior to Beta cut-off of incompatible changes. > > > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > > follows: > > > > Consumer will provide support for interfaces. > > > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > > follows: > > > > No documentation other than header files, comments, and this > > ARC case provided. > > > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > > tested as follows: > > > > Consumer will test interfaces. > > > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > > follows: > > > > Mutual consent. > > > > 15. This contract is not valid until "signed" via agreement from the > > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > > this contract. E-mail agreement to the contract should be archived > > in the mail archive of CASE; verbal agreement to the contract > > should be noted in the meeting minutes. This contract remains > > valid until superseded or invalidated. > > > > For SUPPLIER: Date: > > For CONSUMER: Date: > > For ARC: Date: > > > > A copy of this contract shall be deposited in the CASE directory as > > "contract-" or in a "contracts" subdirectory. > > > > 16. (Not to be filled in until superseded or invalidated.) > > This contract was superseded or invalidated by CASE: > > For ARC: Date: > > > From sacadmin Wed Oct 11 19:34:18 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9C2YHKc028061 for ; Wed, 11 Oct 2006 19:34:18 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9C2atIn016545 for ; Wed, 11 Oct 2006 22:36:55 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9C2atfX016542; Wed, 11 Oct 2006 22:36:55 -0400 (EDT) Date: Wed, 11 Oct 2006 22:36:55 -0400 (EDT) Message-Id: <200610120236.k9C2atfX016542@phorcys.east.sun.com> From: James Carlson To: psarc@sac.sfbay.sun.com Subject: Opinion for review: 2005/474 Zones Upgrade (Ashanti and Zulu) Status: RO Content-Length: 7196 Please review and comment by 10/18/2006. sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Zones Upgrade (Ashanti and Zulu) Submitted by: James Carlson File: PSARC/2005/474/opinion.ms Date: September 21st, 2005 Committee: James D. Carlson, Ed Gould, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary The Zones Upgrade project provides a phased approach towards full support of upgrading Solaris systems with non-global zones. In the first phase, called "Ashanti," patches will be used to deliver the bits that would ordinarily be delivered by packages in a standard upgrade. The second phase, "Zulu," will deliver Live Upgrade and freshbitted package upgrade support. Only Ashanti is fully described by this case. 2. Decision & Precedence Information The project is approved as specified in references [1] through [6]. The project may be delivered in a patch/micro release of Solaris. 3. Interfaces The project exports the following interfaces. _________________________________________________________ | Interfaces Exported | |______________________|_________________|______________| |Interface | Classification | Comments | |______________________|_________________|______________| |nfs_global_client_only| Contracted Pro-| See [1], [5]| | | ject Private | | | | | | |______________________|_________________|______________| PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. - 2 - _________________________________________________________ | Interfaces Exported | |______________________|_________________|______________| |Interface | Classification | Comments | |______________________|_________________|______________| |zlogin -R | Contracted Pro-| See [1], [6]| | | ject Private | | |zoneadm -R {un,}mount | Contracted Pro-| See [1], [6]| | | ject Private | | |{pkg,patch}{add,rm} | Project Private| See [1], [2]| |scratch zone support | Project Private| See [1] | |libzonecfg | Contracted Pro-| See [1], [6]| | | ject Private | | |Jumpstart keywords | Unstable | See [3] | |patch script rules | Sun Private | See [4] | |______________________|_________________|______________| 4. Opinion In general, the ARC members understood that what was being approved in this case represented a time-pressured recovery plan for a bad situation. Thus, although there were clearly unresolved issues that stood out as longer term problems to be addressed, the committee agreed that this project represents one step on that road. 4.1. Case Boundary Several members felt that the case materials left the boun- dary for this case, and therefore what was being approved by the committee, unclear. The case describes the details of Ashanti (references [1] and [2]) and provides an outline of Zulu (reference [7]), but does not contain the full details of the latter. The project team responded that approval of this case would set the contents of Ashanti, and that the plan is to bring future cases to describe the detailed contents of Zulu. The reason for providing some of the Zulu overview in this case is to allow for a discussion of the roadmap, as best it is known now, and to set the expectation for future cases to come. 4.2. NFS And Zones The effect of "Clarification of Cross-Zone Descriptor Res- trictions" (PSARC 2004/357) has come home to roost. That other project effectively outlaws all cross-zone uses of NFS mount points. The miniroot itself (on SPARC systems) is mounted over NFS, PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. - 3 - which means that all of the binaries (including zlogin) are accessed via NFS, and thus cannot invoke zone_enter. In addition, the patch tools assume direct access to the patch and have no mechanism for dealing with file descriptor non- transportability into zones as described in 2004/357. The result is a serious problem for this project, and an /etc/system hack that gets around it in the short term. This issue led to the advice to the PAC, listed in section 6 below. 4.3. The Long Run The long term implications were discussed at some length. The project team indicated that there are many steps on this road, and that there's a project running now that will make this story clearer. However, some rough details are known now. In Update 1, only Standard Upgrade would be supported on all systems, including those that have non-global zones installed. Live Upgrade would work only for systems without non-global zones. This project provides that solution. In Update 2, both Standard and Live Upgrade will work, although it is likely that Standard Upgrade will still use the Ashanti (patch-based) mechanism. A future case will describe the LU (Zulu) changes. In Update 3 or some future update, both forms of upgrade will work, and the plan is to make Standard Upgrade rely on the same underlying mechanisms as Live Upgrade. This will be the end of the Ashanti solution. A future case will describe the Standard Upgrade changes required. Longer term, the plan is to steer customers towards solu- tions that reduce downtime and the pain of patching and upgrades. This means looking at Purple Haze, greater reli- ance on Live Upgrade, and a simplification of the existing code base. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC is advised to fund a project to remove the cross-zone restrictions from NFS. PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. - 4 - 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/474 and are normative. 1. Scratch Zone design document. File: inception.materials/scratchzone-design.pdf 2. Interim (Ashanti) Update design document. File: inception.materials/interimUpdateDesign.txt 3. Jumpstart keyword disposition. File: inception.materials/jumpstart.txt 4. Patch script rules File: final.materials/patch-rules.txt 5. Contract for NFS temporary cross-zone work-around File: final.materials/contract-01.txt 6. Contract for Scratch Zone support File: final.materials/contract-02.txt 7. Zones Upgrade (Zulu) design document. (Non-normative) File: inception.materials/upgradezone-3.3.pdf PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. From sacadmin Thu Oct 12 11:07:25 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9CI7PvC015866 for ; Thu, 12 Oct 2006 11:07:25 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9CI7Ojf021393 for ; Thu, 12 Oct 2006 11:07:25 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9CI7JaF010452 for ; Thu, 12 Oct 2006 11:07:19 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7100K01BMI8500@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 12 Oct 2006 11:07:19 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7100HT9BO7AKMA@d1-sfbay-10.sun.com> for psarc@sac.sfbay.sun.com; Thu, 12 Oct 2006 11:07:19 -0700 (PDT) Date: Thu, 12 Oct 2006 11:07:24 -0700 From: Ed Gould Subject: Re: Opinion for review: 2005/474 Zones Upgrade (Ashanti and Zulu) In-reply-to: <200610120236.k9C2atfX016542@phorcys.east.sun.com> Sender: Ed.Gould@Sun.COM To: James Carlson Cc: psarc@sac.sfbay.sun.com Message-id: <452E845C.8090309@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_7IBYz4ZwwDWYxI3tOAaFDw)" References: <200610120236.k9C2atfX016542@phorcys.east.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 842 This is a multi-part message in MIME format. --Boundary_(ID_7IBYz4ZwwDWYxI3tOAaFDw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT James Carlson wrote: > 4.3. The Long Run > > ... > > In Update 1, ... > > In Update 2, ... > > In Update 3 ... Updates 1, 2 and 3 of what? -- --Ed --Boundary_(ID_7IBYz4ZwwDWYxI3tOAaFDw) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_7IBYz4ZwwDWYxI3tOAaFDw)-- From sacadmin Thu Oct 12 11:14:08 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9CIE8rI016109 for ; Thu, 12 Oct 2006 11:14:08 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9CIGivs004417; Thu, 12 Oct 2006 14:16:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9CIGi9X004414; Thu, 12 Oct 2006 14:16:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17710.34444.404145.921218@gargle.gargle.HOWL> Date: Thu, 12 Oct 2006 14:16:44 -0400 From: James Carlson To: Ed Gould Cc: psarc@sac.sfbay.sun.com Subject: Re: Opinion for review: 2005/474 Zones Upgrade (Ashanti and Zulu) In-Reply-To: <452E845C.8090309@sun.com> References: <200610120236.k9C2atfX016542@phorcys.east.sun.com> <452E845C.8090309@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 325 Ed Gould writes: > > In Update 3 ... > > Updates 1, 2 and 3 of what? Solaris 10. I'll add a note. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Fri Oct 20 08:36:34 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9KFaYZ8007816 for ; Fri, 20 Oct 2006 08:36:34 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9KFdJfr004206 for ; Fri, 20 Oct 2006 11:39:19 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9KFdJcC004203; Fri, 20 Oct 2006 11:39:19 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17720.60838.910578.692176@gargle.gargle.HOWL> Date: Fri, 20 Oct 2006 11:39:18 -0400 From: James Carlson To: sac-review@sac.sfbay.sun.com Subject: Opinion for review: 2005/474 Zones Upgrade (Ashanti and Zulu) X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 7241 Please review and submit any comments by 10/27/2006. sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Zones Upgrade (Ashanti and Zulu) Submitted by: James Carlson File: PSARC/2005/474/opinion.ms Date: September 21st, 2005 Committee: James D. Carlson, Ed Gould, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary The Zones Upgrade project provides a phased approach towards full support of upgrading Solaris systems with non-global zones. In the first phase, called "Ashanti," patches will be used to deliver the bits that would ordinarily be delivered by packages in a standard upgrade. The second phase, "Zulu," will deliver Live Upgrade and freshbitted package upgrade support. Only Ashanti is fully described by this case. 2. Decision & Precedence Information The project is approved as specified in references [1] through [6]. The project may be delivered in a patch/micro release of Solaris. 3. Interfaces The project exports the following interfaces. _________________________________________________________ | Interfaces Exported | |______________________|_________________|______________| |Interface | Classification | Comments | |______________________|_________________|______________| |nfs_global_client_only| Contracted Pro-| See [1], [5]| | | ject Private | | | | | | |______________________|_________________|______________| PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. - 2 - _________________________________________________________ | Interfaces Exported | |______________________|_________________|______________| |Interface | Classification | Comments | |______________________|_________________|______________| |zlogin -R | Contracted Pro-| See [1], [6]| | | ject Private | | |zoneadm -R {un,}mount | Contracted Pro-| See [1], [6]| | | ject Private | | |{pkg,patch}{add,rm} | Project Private| See [1], [2]| |scratch zone support | Project Private| See [1] | |libzonecfg | Contracted Pro-| See [1], [6]| | | ject Private | | |Jumpstart keywords | Unstable | See [3] | |patch script rules | Sun Private | See [4] | |______________________|_________________|______________| 4. Opinion In general, the ARC members understood that what was being approved in this case represented a time-pressured recovery plan for a bad situation. Thus, although there were clearly unresolved issues that stood out as longer term problems to be addressed, the committee agreed that this project represents one step on that road. 4.1. Case Boundary Several members felt that the case materials left the boun- dary for this case, and therefore what was being approved by the committee, unclear. The case describes the details of Ashanti (references [1] and [2]) and provides an outline of Zulu (reference [7]), but does not contain the full details of the latter. The project team responded that approval of this case would set the contents of Ashanti, and that the plan is to bring future cases to describe the detailed contents of Zulu. The reason for providing some of the Zulu overview in this case is to allow for a discussion of the roadmap, as best it is known now, and to set the expectation for future cases to come. 4.2. NFS And Zones The effect of "Clarification of Cross-Zone Descriptor Res- trictions" (PSARC 2004/357) has come home to roost. That other project effectively outlaws all cross-zone uses of NFS mount points. The miniroot itself (on SPARC systems) is mounted over NFS, PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. - 3 - which means that all of the binaries (including zlogin) are accessed via NFS, and thus cannot invoke zone_enter. In addition, the patch tools assume direct access to the patch and have no mechanism for dealing with file descriptor non- transportability into zones as described in 2004/357. The result is a serious problem for this project, and an /etc/system hack that gets around it in the short term. This issue led to the advice to the PAC, listed in section 6 below. 4.3. The Long Run The long term implications were discussed at some length. The project team indicated that there are many steps on this road, and that there's a project running now that will make this story clearer. However, some rough details are known now for the Solaris 10 Update series. In Update 1, only Standard Upgrade would be supported on all systems, including those that have non-global zones installed. Live Upgrade would work only for systems without non-global zones. This project provides that solution. In Update 2, both Standard and Live Upgrade will work, although it is likely that Standard Upgrade will still use the Ashanti (patch-based) mechanism. A future case will describe the LU (Zulu) changes. In Update 3 or some future update, both forms of upgrade will work, and the plan is to make Standard Upgrade rely on the same underlying mechanisms as Live Upgrade. This will be the end of the Ashanti solution. A future case will describe the Standard Upgrade changes required. Longer term, the plan is to steer customers towards solu- tions that reduce downtime and the pain of patching and upgrades. This means looking at Purple Haze, greater reli- ance on Live Upgrade, and a simplification of the existing code base. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC is advised to fund a project to remove the cross-zone restrictions from NFS. PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. - 4 - 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/474 and are normative. 1. Scratch Zone design document. File: inception.materials/scratchzone-design.pdf 2. Interim (Ashanti) Update design document. File: inception.materials/interimUpdateDesign.txt 3. Jumpstart keyword disposition. File: inception.materials/jumpstart.txt 4. Patch script rules File: final.materials/patch-rules.txt 5. Contract for NFS temporary cross-zone work-around File: final.materials/contract-01.txt 6. Contract for Scratch Zone support File: final.materials/contract-02.txt 7. Zones Upgrade (Zulu) design document. (Non-normative) File: inception.materials/upgradezone-3.3.pdf PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. From sac-owner Wed Nov 1 06:18:55 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA1EIsd2009756 for ; Wed, 1 Nov 2006 06:18:54 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kA1ELnie024247; Wed, 1 Nov 2006 09:21:49 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id kA1ELn8R024244; Wed, 1 Nov 2006 09:21:49 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17736.44412.880413.376285@gargle.gargle.HOWL> Date: Wed, 1 Nov 2006 09:21:48 -0500 From: James Carlson To: sac-opinion@sac.sfbay.sun.com cc: solaris-pac-opinion@Sun.Com Subject: Opinion: 2005/474 Zones Upgrade (Ashanti and Zulu) X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 7187 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Zones Upgrade (Ashanti and Zulu) Submitted by: James Carlson File: PSARC/2005/474/opinion.ms Date: September 21st, 2005 Committee: James D. Carlson, Ed Gould, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary The Zones Upgrade project provides a phased approach towards full support of upgrading Solaris systems with non-global zones. In the first phase, called "Ashanti," patches will be used to deliver the bits that would ordinarily be delivered by packages in a standard upgrade. The second phase, "Zulu," will deliver Live Upgrade and freshbitted package upgrade support. Only Ashanti is fully described by this case. 2. Decision & Precedence Information The project is approved as specified in references [1] through [6]. The project may be delivered in a patch/micro release of Solaris. 3. Interfaces The project exports the following interfaces. _________________________________________________________ | Interfaces Exported | |______________________|_________________|______________| |Interface | Classification | Comments | |______________________|_________________|______________| |nfs_global_client_only| Contracted Pro-| See [1], [5]| | | ject Private | | | | | | |______________________|_________________|______________| PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. - 2 - _________________________________________________________ | Interfaces Exported | |______________________|_________________|______________| |Interface | Classification | Comments | |______________________|_________________|______________| |zlogin -R | Contracted Pro-| See [1], [6]| | | ject Private | | |zoneadm -R {un,}mount | Contracted Pro-| See [1], [6]| | | ject Private | | |{pkg,patch}{add,rm} | Project Private| See [1], [2]| |scratch zone support | Project Private| See [1] | |libzonecfg | Contracted Pro-| See [1], [6]| | | ject Private | | |Jumpstart keywords | Unstable | See [3] | |patch script rules | Sun Private | See [4] | |______________________|_________________|______________| 4. Opinion In general, the ARC members understood that what was being approved in this case represented a time-pressured recovery plan for a bad situation. Thus, although there were clearly unresolved issues that stood out as longer term problems to be addressed, the committee agreed that this project represents one step on that road. 4.1. Case Boundary Several members felt that the case materials left the boun- dary for this case, and therefore what was being approved by the committee, unclear. The case describes the details of Ashanti (references [1] and [2]) and provides an outline of Zulu (reference [7]), but does not contain the full details of the latter. The project team responded that approval of this case would set the contents of Ashanti, and that the plan is to bring future cases to describe the detailed contents of Zulu. The reason for providing some of the Zulu overview in this case is to allow for a discussion of the roadmap, as best it is known now, and to set the expectation for future cases to come. 4.2. NFS And Zones The effect of "Clarification of Cross-Zone Descriptor Res- trictions" (PSARC 2004/357) has come home to roost. That other project effectively outlaws all cross-zone uses of NFS mount points. The miniroot itself (on SPARC systems) is mounted over NFS, PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. - 3 - which means that all of the binaries (including zlogin) are accessed via NFS, and thus cannot invoke zone_enter. In addition, the patch tools assume direct access to the patch and have no mechanism for dealing with file descriptor non- transportability into zones as described in 2004/357. The result is a serious problem for this project, and an /etc/system hack that gets around it in the short term. This issue led to the advice to the PAC, listed in section 6 below. 4.3. The Long Run The long term implications were discussed at some length. The project team indicated that there are many steps on this road, and that there's a project running now that will make this story clearer. However, some rough details are known now for the Solaris 10 Update series. In Update 1, only Standard Upgrade would be supported on all systems, including those that have non-global zones installed. Live Upgrade would work only for systems without non-global zones. This project provides that solution. In Update 2, both Standard and Live Upgrade will work, although it is likely that Standard Upgrade will still use the Ashanti (patch-based) mechanism. A future case will describe the LU (Zulu) changes. In Update 3 or some future update, both forms of upgrade will work, and the plan is to make Standard Upgrade rely on the same underlying mechanisms as Live Upgrade. This will be the end of the Ashanti solution. A future case will describe the Standard Upgrade changes required. Longer term, the plan is to steer customers towards solu- tions that reduce downtime and the pain of patching and upgrades. This means looking at Purple Haze, greater reli- ance on Live Upgrade, and a simplification of the existing code base. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC is advised to fund a project to remove the cross-zone restrictions from NFS. PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc. - 4 - 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/474 and are normative. 1. Scratch Zone design document. File: inception.materials/scratchzone-design.pdf 2. Interim (Ashanti) Update design document. File: inception.materials/interimUpdateDesign.txt 3. Jumpstart keyword disposition. File: inception.materials/jumpstart.txt 4. Patch script rules File: final.materials/patch-rules.txt 5. Contract for NFS temporary cross-zone work-around File: final.materials/contract-01.txt 6. Contract for Scratch Zone support File: final.materials/contract-02.txt 7. Zones Upgrade (Zulu) design document. (Non-normative) File: inception.materials/upgradezone-3.3.pdf PSARC/2005/474 Copyright 2005 Sun Microsystems, Inc.