@(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] [This is a template for the Contract associated with Contracted interfaces (i.e. Contracted Consolidation Private, Contracted Project Private, etc). It must be tailored for each use, and be approved as part of the case approving the interfaces. Remove the explanatory text in square brackets before using this template. This is NOT a legal contract; it is simply a mechanism used to specify the details of an unusual dependency between two components that is not allowed under the normal rules set forth in the interface taxonomy.] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2007/454 (Contract to share infiniband rds interfaces with Solaris Cluster.) 1. This contract is between Sun Cluster (Consumer of interface) and Solaris (Supplier) 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: OPG Bugtraq Product/Category/SubCategory: solaris/ib_sw/rds-ib Product: solaris Responsible Manager: Lii Chen 3. The CONSUMER is identified by the following: Product or Bundle: Sun Cluster Consolidation: Sun Cluster Department or Group: Solaris Bugtraq Product/Category/SubCategory: suncluster/suncluster/transport Product: Sun Cluster Responsible Manager: Burt Clouse 4. The INTERFACES are: Private interface between SC and RDS to allow callbacks for monitoring status of SC paths. (See below for more details on the usage.) Interfaces Exported ___________________________________________________________________ | Interface | Classification | Comments | ___________________________________________________________________ | rds_clif_name() | Contract Private | Use by Solaris Cluster | | rds_path_up() | Contract Private | Use by Solaris Cluster | | rds_path_down() | Contract Private | Use by Solaris Cluster | ___________________________________________________________________ Defined in usr/src/uts/common/sys/ib/clients/rds/rdsib_sc.h typedef struct rds_path_endpoint_s { uint32_t iftype; ipaddr_t ipaddr; ipaddr_t node_ipaddr; char *ifname; } rds_path_endpoint_t; where ifname name of physical interface (e.g. ibd1, e1000g1) iftype type of physical medium (e.g. DL_IB, DL_ETHER) ipaddr IP address hosted on interface node_ipaddr IP address for Cluster private communication over clprivnet0 (virtual SC interface) typedef struct rds_path_s { rds_path_endpoint_t local; rds_path_endpoint_t remote; } rds_path_t; extern void rds_clif_name(char *name); extern void rds_path_up(struct rds_path_s *path); extern void rds_path_down(struct rds_path_s *path); 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing (Exporting) these INTERFACES is: PSARC 2006/356: RDS 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: [Indicate all that apply by changing the N to a Y and fill in blanks as applicable...] [Paragraph used to control changes to External interfaces.] _N_ 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: [describe conditions, e.g. "minor release"] [Paragraph used to expose interfaces privately to partners.] _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: [Paragraph used to expose interfaces across consolidations.] _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. [Paragraph used to mandate notification before interfaces change.] _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 particular, include whether the SUPPLIER will inform the CONSUMER or obtain approval of the change from the CONSUMER.] Evolution should be jointly developed. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: As the interface becomes the integrated part of the product, the support channel would be normal as usual (ie. bug/escalation channel) from either by Supplier or by Consumer, or in some cases by both supplier and consumer depends on the nature of support/problem. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: Interfaces are documented at the end of this contract. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: Joint effort in-house testing. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: With consent of Consumer only. 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: Lii Chen Date: 8/7/2007 For CONSUMER: Burt Clouse Date: 8/9/2007 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: Supplemental: Interface Definition and Usage --------------------------------------------- See /shared/SC/dev-process/features/2007/1611/sc_rds_proposal.txt /shared/SC/dev-process/features/2007/1611/rds-contract-manpages.txt