From - Tue May 29 12:37:41 2007 Date: Thu, 24 May 2007 18:25:31 -0700 From: Jerri-Ann Meyer Subject: Re: "Cluster" BrandZ contract In-reply-to: <4656350D.5090004@sun.com> To: Ellard.Roush@Sun.COM Cc: Charles DeBardeleben , Dan Price Reply-to: jerriann.meyer@sun.com Message-id: <46563B0B.4070305@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4656350D.5090004@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Ellard Roush wrote: > Hi Jerri-Ann, > > Attached below is the contract covering the use fast track case > for the cluster BrandZ zone. > > After that is the actual fast track case. > > Dan and I talked to you this evening about the > time factor. Please respond that you approve. I approve. jerri-ann > > Regards, > Ellard > > ------------------------------------------------------- > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2007/? > > 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: Sun Cluster > Consolidation: Sun Cluster > Department or Group: Sun Cluster Infrastructure > Bugtraq Category/SubCategory: suncluster/zones > Responsible Manager: Burt Clouse > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: ON > Department or Group: Solaris Core Technologies > Bugtraq Category/SubCategory: kernel/zones > Responsible Manager: Jerri-Ann Meyers > > 4. The INTERFACES are: > > INTERFACE STABILITY > > The zoneadm/zoneadmd Project private > software will treat > zone brand "native" and > "cluster" the same. > > 5. The ARC controlling these INTERFACES is: > > PSARC > > 6. The CASE describing these INTERFACES is: > > PSARC 2002/174 - Virtualization and Namespace Isolation in Solaris > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > > _N_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > SUPPLIER agrees to only change the contracted interface > in an incompatible manner in a new minor release. > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER > will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER > will > import INTERFACES from a separate consolidation. > > > SUPPLIER will notify CONSUMER of any changes to the interface. > > _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. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > > SUPPLIER will notify CONSUMER of any proposed changes to the > interface. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > CONSUMER shall file bugster change requests against the > interfaces under solaris/kernel/zones. SUPPLIER agrees to > respond to these change requests according to the usual > sustaining process. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > The materials in this case. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > SUPPLIER agrees to test any changes to the interface as part of > existing or updated test suites. CONSUMER agrees to test their > use of these interfaces at the usual release intervals and when > any changes are made to the implementation of the contracted > interface. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > Contract will be terminated by mutual agreement between the > SUPPLIER and CONSUMER. > > 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: Burt Clouse Date: > For CONSUMER: Jerri-Ann Meyers 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: > > > --------------------------------------- > Subject: PSARC FastTrack [05/22/2007]: "Cluster" Brand Zone > > Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI > This information is Copyright 2007 Sun Microsystems, Inc. > 1. Introduction > 1.1. Project/Component Working Name: > "Cluster" Brand Zone > 1.2. Name of Document Author/Supplier: > Author: Ellard Roush > 1.3 Date of This Document: > 22 May 2007 > > 4. Technical Description > > The BrandZ feature set provides a way to tailor the behavior > of a zone via a set of callbacks for specific purposes, such > as zone boot, zone halt, zone install, etc. > > This case reserves a new brand type, "cluster", which will be used > to implement a zone aware Solaris Cluster product. This product > supports the ability to run Oracle RAC in Zones, as well as other > cluster applications. The "cluster" brand will be released > as part of a Sun Cluster product release that will run on > Solaris 10 update 4. > > The "cluster" brand type is closely related to the "native" > brand type. Essentially, the "cluster" zone uses the callback > mechanism in order to do things in addition to what the "native" > brand type does. For example, the cluster code learns about zone > halt with the "zone halt" callback and still executes the "native" > "zone halt" callback function. > > The first non-native brand was the "lx" brand, which implements a > Linux user-space environment. Since lx-branded zones contain only > Linux software, the Solaris tools used for installing, patching, and > upgrading zones were modified to bypass lx-branded zones. This bypass > was implemented in a heavy-handed way, and it actually causes the > tools to bypass all non-native zones. > > Cluster-branded zones contain native Solaris software, and must be > subject to all the same installation, patching, and upgrade processes > as a native zone. > > The support for other zone brands, such as "lx", will continue to be > as defined in "PSARC/2003/460 - Admin/Install Zones Support". > > This approach is considered an interim solution, and is being taken > due to the tight time constraints to get into Solaris 10 update 4. A > more generic solution will be implemented as a follow-on to this > project. That solution will add new interfaces to the BrandZ > infrastructure, which will allow us to remove any special knowledge of > the "cluster" brand from the zones utilities. The specification of > these interfaces will be submitted as a separate PSARC case. > > Without the change proposed in this fast track case, Solaris Cluster > could not support Oracle RAC in Zones with Solaris 10 update 4. > That is very important for the cluster product and would be a STOPPER > issue for that product. Thus we chose to follow the path of > an interim solution for S10u4 followed by the long term solution. > > 5. Reference Documents > PSARC/2003/460 - Admin/Install Zones Support > PSARC/2005/471 - BrandZ: Support for non-native zones > PSARC/2006/440 - BrandZ -aware Installer > > CLARC/2004/1405 - RAC on Zones (see requirement specification > in /shared/SC/dev-process/features/2004/1405) > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > From - Tue May 29 12:37:54 2007 Date: Fri, 25 May 2007 05:29:58 -0600 From: Eric Ray Subject: Re: Cluster BrandZ contract - Urgent In-reply-to: <46563668.60505@sun.com> Sender: Eric.Ray@sun.com To: Ellard.Roush@Sun.COM Cc: Charles DeBardeleben , Ethan.Quach@Sun.COM Message-id: <4656C8B6.4030100@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46563668.60505@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Approve. Ellard Roush wrote: > Hi Eric, > > The Solaris 10 update 4 gatekeeper just informed > me that we need to putback by Tuesday. > > We have filed the Fast Track case. > We will try to have that approved as a self review > so that we can putback on Tuesday. > > Please reply that you agree to the contract. > Please do so quickly because of the time factor. > > The contract has been reviewed by Install team > members. Please contact Ethan Quach if you > have any questions. > > Attached below is the contract. > Also, the fast track is attached after the contract. > > Regards, > Ellard > > ------------------------------------------------- > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2007/? > > 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: Sun Cluster > Consolidation: Sun Cluster > Department or Group: Sun Cluster Infrastructure > Bugtraq Category/SubCategory: suncluster/zones > Responsible Manager: Burt Clouse > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: Install > Department or Group: Solaris Install Technologies > Bugtraq Category/SubCategory: > sysadmin/pkg_commands > solaris_install/live-upgrade > Responsible Manager: Eric Ray > > 4. The INTERFACES are: > > INTERFACE STABILITY > > The packaging/patching/ Project private > installation/upgrade > software will treat > zone brand "native" and > "cluster" the same. > > 5. The ARC controlling these INTERFACES is: > > PSARC > > 6. The CASE describing these INTERFACES is: > > PSARC 2002/174 - Virtualization and Namespace Isolation in Solaris > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > > _N_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > SUPPLIER agrees to only change the contracted interface > in an incompatible manner in a new minor release. > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER > will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER > will > import INTERFACES from a separate consolidation. > > > SUPPLIER will notify CONSUMER of any changes to the interface. > > _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. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > > SUPPLIER will notify CONSUMER of any proposed changes to the > interface. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > CONSUMER shall file bugster change requests against the > interfaces under solaris/kernel/zones. SUPPLIER agrees to > respond to these change requests according to the usual > sustaining process. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > The materials in this case. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > SUPPLIER agrees to test any changes to the interface as part of > existing or updated test suites. CONSUMER agrees to test their > use of these interfaces at the usual release intervals and when > any changes are made to the implementation of the contracted > interface. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > Contract will be terminated by mutual agreement between the > SUPPLIER and CONSUMER. > > 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: Burt Clouse Date: > For CONSUMER: Eric Ray 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: > > ----------------------------------------------------------------- > > Subject: PSARC FastTrack [05/22/2007]: "Cluster" Brand Zone > > Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI > This information is Copyright 2007 Sun Microsystems, Inc. > 1. Introduction > 1.1. Project/Component Working Name: > "Cluster" Brand Zone > 1.2. Name of Document Author/Supplier: > Author: Ellard Roush > 1.3 Date of This Document: > 22 May 2007 > > 4. Technical Description > > The BrandZ feature set provides a way to tailor the behavior > of a zone via a set of callbacks for specific purposes, such > as zone boot, zone halt, zone install, etc. > > This case reserves a new brand type, "cluster", which will be used > to implement a zone aware Solaris Cluster product. This product > supports the ability to run Oracle RAC in Zones, as well as other > cluster applications. The "cluster" brand will be released > as part of a Sun Cluster product release that will run on > Solaris 10 update 4. > > The "cluster" brand type is closely related to the "native" > brand type. Essentially, the "cluster" zone uses the callback > mechanism in order to do things in addition to what the "native" > brand type does. For example, the cluster code learns about zone > halt with the "zone halt" callback and still executes the "native" > "zone halt" callback function. > > The first non-native brand was the "lx" brand, which implements a > Linux user-space environment. Since lx-branded zones contain only > Linux software, the Solaris tools used for installing, patching, and > upgrading zones were modified to bypass lx-branded zones. This bypass > was implemented in a heavy-handed way, and it actually causes the > tools to bypass all non-native zones. > > Cluster-branded zones contain native Solaris software, and must be > subject to all the same installation, patching, and upgrade processes > as a native zone. > > The support for other zone brands, such as "lx", will continue to be > as defined in "PSARC/2003/460 - Admin/Install Zones Support". > > This approach is considered an interim solution, and is being taken > due to the tight time constraints to get into Solaris 10 update 4. A > more generic solution will be implemented as a follow-on to this > project. That solution will add new interfaces to the BrandZ > infrastructure, which will allow us to remove any special knowledge of > the "cluster" brand from the zones utilities. The specification of > these interfaces will be submitted as a separate PSARC case. > > Without the change proposed in this fast track case, Solaris Cluster > could not support Oracle RAC in Zones with Solaris 10 update 4. > That is very important for the cluster product and would be a STOPPER > issue for that product. Thus we chose to follow the path of > an interim solution for S10u4 followed by the long term solution. > > 5. Reference Documents > PSARC/2003/460 - Admin/Install Zones Support > PSARC/2005/471 - BrandZ: Support for non-native zones > PSARC/2006/440 - BrandZ -aware Installer > > CLARC/2004/1405 - RAC on Zones (see requirement specification > in /shared/SC/dev-process/features/2004/1405) > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > > -- Eric J. Ray Software Engineering Manager Solaris Install Sun Microsystems 303-223-7843 (direct)/x81067 eric.ray@sun.com From - Tue May 29 12:38:12 2007 Date: Tue, 29 May 2007 07:12:15 -0700 From: Burt Clouse Subject: Re: "Cluster" BrandZ contract] In-reply-to: <46574BBA.20300@sun.com> Sender: Burt.Clouse@Sun.COM To: Ellard.Roush@Sun.COM Cc: Charles DeBardeleben Message-id: <465C34BF.2050204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46574BBA.20300@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061110) I approve. -Burt roush wrote: > Hi Burt, > > We also need you to approve this contract. > Please reply by email with your approval. > We need this Tuesday. > This will be recorded in the case directory. > > Thanks, > Ellard > > -------- Original Message -------- > Subject: "Cluster" BrandZ contract > Date: Thu, 24 May 2007 17:59:57 -0700 > From: Ellard Roush > Reply-To: Ellard.Roush@Sun.COM > To: jerriann.meyer@sun.com, ELLARD ROUSH , > Charles DeBardeleben > > Hi Jerri-Ann, > > Attached below is the contract covering the use fast track case > for the cluster BrandZ zone. > > After that is the actual fast track case. > > Dan and I talked to you this evening about the > time factor. Please respond that you approve. > > Regards, > Ellard > > ------------------------------------------------------- > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2007/? > > 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: Sun Cluster > Consolidation: Sun Cluster > Department or Group: Sun Cluster Infrastructure > Bugtraq Category/SubCategory: suncluster/zones > Responsible Manager: Burt Clouse > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: ON > Department or Group: Solaris Core Technologies > Bugtraq Category/SubCategory: kernel/zones > Responsible Manager: Jerri-Ann Meyers > > 4. The INTERFACES are: > > INTERFACE STABILITY > > The zoneadm/zoneadmd Project private > software will treat > zone brand "native" and > "cluster" the same. > > 5. The ARC controlling these INTERFACES is: > > PSARC > > 6. The CASE describing these INTERFACES is: > > PSARC 2002/174 - Virtualization and Namespace Isolation in Solaris > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > > _N_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > SUPPLIER agrees to only change the contracted interface > in an incompatible manner in a new minor release. > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER > will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER > will > import INTERFACES from a separate consolidation. > > > SUPPLIER will notify CONSUMER of any changes to the interface. > > _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. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > > SUPPLIER will notify CONSUMER of any proposed changes to the > interface. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > CONSUMER shall file bugster change requests against the > interfaces under solaris/kernel/zones. SUPPLIER agrees to > respond to these change requests according to the usual > sustaining process. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > The materials in this case. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > SUPPLIER agrees to test any changes to the interface as part of > existing or updated test suites. CONSUMER agrees to test their > use of these interfaces at the usual release intervals and when > any changes are made to the implementation of the contracted > interface. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > Contract will be terminated by mutual agreement between the > SUPPLIER and CONSUMER. > > 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: Burt Clouse Date: > For CONSUMER: Jerri-Ann Meyers 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: > > > --------------------------------------- > Subject: PSARC FastTrack [05/22/2007]: "Cluster" Brand Zone > > Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI > This information is Copyright 2007 Sun Microsystems, Inc. > 1. Introduction > 1.1. Project/Component Working Name: > "Cluster" Brand Zone > 1.2. Name of Document Author/Supplier: > Author: Ellard Roush > 1.3 Date of This Document: > 22 May 2007 > > 4. Technical Description > > The BrandZ feature set provides a way to tailor the behavior > of a zone via a set of callbacks for specific purposes, such > as zone boot, zone halt, zone install, etc. > > This case reserves a new brand type, "cluster", which will be used > to implement a zone aware Solaris Cluster product. This product > supports the ability to run Oracle RAC in Zones, as well as other > cluster applications. The "cluster" brand will be released > as part of a Sun Cluster product release that will run on > Solaris 10 update 4. > > The "cluster" brand type is closely related to the "native" > brand type. Essentially, the "cluster" zone uses the callback > mechanism in order to do things in addition to what the "native" > brand type does. For example, the cluster code learns about zone > halt with the "zone halt" callback and still executes the "native" > "zone halt" callback function. > > The first non-native brand was the "lx" brand, which implements a > Linux user-space environment. Since lx-branded zones contain only > Linux software, the Solaris tools used for installing, patching, and > upgrading zones were modified to bypass lx-branded zones. This > bypass > was implemented in a heavy-handed way, and it actually causes the > tools to bypass all non-native zones. > > Cluster-branded zones contain native Solaris software, and must be > subject to all the same installation, patching, and upgrade processes > as a native zone. > > The support for other zone brands, such as "lx", will continue to be > as defined in "PSARC/2003/460 - Admin/Install Zones Support". > > This approach is considered an interim solution, and is being taken > due to the tight time constraints to get into Solaris 10 update 4. A > more generic solution will be implemented as a follow-on to this > project. That solution will add new interfaces to the BrandZ > infrastructure, which will allow us to remove any special > knowledge of > the "cluster" brand from the zones utilities. The specification of > these interfaces will be submitted as a separate PSARC case. > > Without the change proposed in this fast track case, Solaris Cluster > could not support Oracle RAC in Zones with Solaris 10 update 4. > That is very important for the cluster product and would be a STOPPER > issue for that product. Thus we chose to follow the path of > an interim solution for S10u4 followed by the long term solution. > > 5. Reference Documents > PSARC/2003/460 - Admin/Install Zones Support > PSARC/2005/471 - BrandZ: Support for non-native zones > PSARC/2006/440 - BrandZ -aware Installer > > CLARC/2004/1405 - RAC on Zones (see requirement specification > in /shared/SC/dev-process/features/2004/1405) > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > From - Tue May 29 12:38:21 2007 Date: Tue, 29 May 2007 07:12:29 -0700 From: Burt Clouse Subject: Re: [Fwd: Cluster BrandZ contract - Urgent] In-reply-to: <46574C22.4030501@sun.com> Sender: Burt.Clouse@Sun.COM To: Ellard.Roush@Sun.COM Cc: Charles DeBardeleben , Ethan.Quach@Sun.COM Message-id: <465C34CD.60705@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46574C22.4030501@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061110) I approve. -Burt roush wrote: > Hi Burt, > > We need your approval via email for this contract. > This is needed by Tuesday. > Your email will be recorded in the case directory, > like the other contract that I just sent you. > > Regards, > Ellard > > -------- Original Message -------- > Subject: Cluster BrandZ contract - Urgent > Date: Thu, 24 May 2007 18:05:44 -0700 > From: Ellard Roush > Reply-To: Ellard.Roush@Sun.COM > To: Eric.Ray@sun.com, ELLARD ROUSH , Charles > DeBardeleben , Ethan.Quach@Sun.COM > > Hi Eric, > > The Solaris 10 update 4 gatekeeper just informed > me that we need to putback by Tuesday. > > We have filed the Fast Track case. > We will try to have that approved as a self review > so that we can putback on Tuesday. > > Please reply that you agree to the contract. > Please do so quickly because of the time factor. > > The contract has been reviewed by Install team > members. Please contact Ethan Quach if you > have any questions. > > Attached below is the contract. > Also, the fast track is attached after the contract. > > Regards, > Ellard > > ------------------------------------------------- > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2007/? > > 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: Sun Cluster > Consolidation: Sun Cluster > Department or Group: Sun Cluster Infrastructure > Bugtraq Category/SubCategory: suncluster/zones > Responsible Manager: Burt Clouse > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: Install > Department or Group: Solaris Install Technologies > Bugtraq Category/SubCategory: > sysadmin/pkg_commands > solaris_install/live-upgrade > Responsible Manager: Eric Ray > > 4. The INTERFACES are: > > INTERFACE STABILITY > > The packaging/patching/ Project private > installation/upgrade > software will treat > zone brand "native" and > "cluster" the same. > > 5. The ARC controlling these INTERFACES is: > > PSARC > > 6. The CASE describing these INTERFACES is: > > PSARC 2002/174 - Virtualization and Namespace Isolation in Solaris > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > > _N_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > SUPPLIER agrees to only change the contracted interface > in an incompatible manner in a new minor release. > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER > will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER > will > import INTERFACES from a separate consolidation. > > > SUPPLIER will notify CONSUMER of any changes to the interface. > > _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. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > > SUPPLIER will notify CONSUMER of any proposed changes to the > interface. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > CONSUMER shall file bugster change requests against the > interfaces under solaris/kernel/zones. SUPPLIER agrees to > respond to these change requests according to the usual > sustaining process. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > The materials in this case. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > SUPPLIER agrees to test any changes to the interface as part of > existing or updated test suites. CONSUMER agrees to test their > use of these interfaces at the usual release intervals and when > any changes are made to the implementation of the contracted > interface. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > Contract will be terminated by mutual agreement between the > SUPPLIER and CONSUMER. > > 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: Burt Clouse Date: > For CONSUMER: Eric Ray 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: > > ----------------------------------------------------------------- > > Subject: PSARC FastTrack [05/22/2007]: "Cluster" Brand Zone > > Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI > This information is Copyright 2007 Sun Microsystems, Inc. > 1. Introduction > 1.1. Project/Component Working Name: > "Cluster" Brand Zone > 1.2. Name of Document Author/Supplier: > Author: Ellard Roush > 1.3 Date of This Document: > 22 May 2007 > > 4. Technical Description > > The BrandZ feature set provides a way to tailor the behavior > of a zone via a set of callbacks for specific purposes, such > as zone boot, zone halt, zone install, etc. > > This case reserves a new brand type, "cluster", which will be used > to implement a zone aware Solaris Cluster product. This product > supports the ability to run Oracle RAC in Zones, as well as other > cluster applications. The "cluster" brand will be released > as part of a Sun Cluster product release that will run on > Solaris 10 update 4. > > The "cluster" brand type is closely related to the "native" > brand type. Essentially, the "cluster" zone uses the callback > mechanism in order to do things in addition to what the "native" > brand type does. For example, the cluster code learns about zone > halt with the "zone halt" callback and still executes the "native" > "zone halt" callback function. > > The first non-native brand was the "lx" brand, which implements a > Linux user-space environment. Since lx-branded zones contain only > Linux software, the Solaris tools used for installing, patching, and > upgrading zones were modified to bypass lx-branded zones. This > bypass > was implemented in a heavy-handed way, and it actually causes the > tools to bypass all non-native zones. > > Cluster-branded zones contain native Solaris software, and must be > subject to all the same installation, patching, and upgrade processes > as a native zone. > > The support for other zone brands, such as "lx", will continue to be > as defined in "PSARC/2003/460 - Admin/Install Zones Support". > > This approach is considered an interim solution, and is being taken > due to the tight time constraints to get into Solaris 10 update 4. A > more generic solution will be implemented as a follow-on to this > project. That solution will add new interfaces to the BrandZ > infrastructure, which will allow us to remove any special > knowledge of > the "cluster" brand from the zones utilities. The specification of > these interfaces will be submitted as a separate PSARC case. > > Without the change proposed in this fast track case, Solaris Cluster > could not support Oracle RAC in Zones with Solaris 10 update 4. > That is very important for the cluster product and would be a STOPPER > issue for that product. Thus we chose to follow the path of > an interim solution for S10u4 followed by the long term solution. > > 5. Reference Documents > PSARC/2003/460 - Admin/Install Zones Support > PSARC/2005/471 - BrandZ: Support for non-native zones > PSARC/2006/440 - BrandZ -aware Installer > > CLARC/2004/1405 - RAC on Zones (see requirement specification > in /shared/SC/dev-process/features/2004/1405) > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > >