Subject: Re: contract for PSARC 2006/372 From: Peter Luk Date: Tue, 06 Jun 2006 12:48:20 -0700 To: Hyon Kim CC: ramaswamy.tummala@sun.com, Vincent.Eberhard@Sun.COM, Paul von Behren , Carla Mowers , Chris Horne Approved. -Pete Hyon Kim wrote On 06/06/06 11:50,: > Ramaswamy Tummala wrote: > >> A contract is between two parties signed by managers from the both the parties. >> Since Vincent is responsible RM for fcp, I don't see any issue adding the >> interfaces I specified to this contract. For FC side, the bugtraq category >> is kernel/kernel_driver_fc_ulp_fcp (this is the same as the one you already >> specified in the contract). Though the change will be made to fp.conf, this >> is really FCP ULP related change and hence the kernel_driver_fc_ulp_fcp >> category. >> >> > The fp.conf is associated with the fp driver which has > > kernel_driver_fc_transport subcat. I might not be clear enough in my previous email. > > >> For the iscsi side, I understand that Vincent is not the responsible RM >> (please correct me if I am wrong). So we can cover the iscsi side in >> a different contract (unless we ask Scott to sign the contract in which >> case I think it is OK to cover both FCP and iSCSI in a single contract). >> >> > Ken Davis owns the iscsi. > >> If you are still not comfortable adding these interfaces to the contract >> you may omit them (we'll have to file another contract in the future >> in this case.). >> >> > One other reason why I suggest to have a seperate contract is that > PSARC 2006/372 complements PSARC/2006/103 and specifically mentions the interfaces > from PSARC/2006/103. In order to include the interfaces you specified > PSARC 2006/372 may need to mention fasttrack PSARC/2006/285 for those interfaces as well. We have had a fasttrack to just handle a contract and I believe that makes the > context of the contract more clear. > > I would like to proceed with the contract as it is. > > Peter, > > Would you please send me an approval mail if you don't have a further issue? > > Thanks, > Hyon > >> Thanks, >> Ramaswamy. >> >> Hyon Kim wrote On 06/05/06 18:18,: >> >> >>> I understand tha the ARC contract goes by Bugster cat/subcat not by the whole consolidation and >>> the NWS has been following it. Currently for the same set of MDI interfaces, iSCSI and FC have >>> different contracts. Considering that the NWS consumers of PSARC/2006/285 related interfaces >>> are kernel/driver-iscsi and san_foundation_kit/kernel_driver_fc_transport_fp, we may need to do >>> the followings. >>> >>> - Update existing iSCSI contract, PSARC/2003/126 contract-04 >>> >>> AND >>> >>> - Create a new contract for kernel_driver_fc_transport_fp. >>> >>> The consumer of PSARC/2006/372 contract is kernel_driver_fc_ulp_fcp. >>> so I think we should proceed the contract as it is. >>> >>> Let me know if you have a different understanding. . >>> >>> --Hyon >>> >>> Ramaswamy Tummala wrote: >>> >>> >>> >>> >>>> Not yet as these two interfaces will need to be contracted before adding them >>>> to iscsi and fp .conf files. >>>> >>>> Thanks, >>>> Ramaswamy. >>>> >>>> Hyon Kim wrote: >>>> >>>> >>>> >>>> >>>>> Have the iscsi and fp driver added the interfaces to the .conf? >>>>> >>>>> --Hyon >>>>> >>>>> Ramaswamy Tummala wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> These interfaces will need to contracted by NWS anyway. Including them >>>>>> in this contract saves us from running another contract in the future. >>>>>> >>>>>> Thanks, >>>>>> Ramaswamy. >>>>>> >>>>>> Peter Luk wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Per recommendation from Ramaswamy, we would like to see the >>>>>>> following interfaces included in the contract: >>>>>>> >>>>>>> ddi-vhci-class property Contracted Consolidation Priv >>>>>>> ddi-no-root-support property Contracted Consolidation Priv >>>>>>> >>>>>>> ARC controlling these interfaces is PSARC 2006/285 >>>>>>> >>>>>>> Let us know if this is not acceptable, otherwise I approve >>>>>>> this agreement. >>>>>>> >>>>>>> -Pete >>>>>>> >>>>>>> >>>>>>> Vincent Eberhard wrote On 06/01/06 17:43,: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hyon, >>>>>>>> >>>>>>>> I approve this agreement. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> >>>>>>>> Vince >>>>>>>> >>>>>>>> Hyon Kim wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi Vince and Peter, >>>>>>>>> >>>>>>>>> As part of PSARC 2006/372, the contract for mdi_pi_enable/disable_path needs to >>>>>>>>> be provided for NWS use of the interfaces. Please review the contract and let me know >>>>>>>>> if you have any issues. Otherwise please send me an approval email. Your prompt review >>>>>>>>> will be appreciated. >>>>>>>>> >>>>>>>>> I have also attached the fastrack email. >>>>>>>>> >>>>>>>>> --Hyon >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] >>>>>>>>> >>>>>>>>> CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES >>>>>>>>> >>>>>>>>> 0. Number: >>>>>>>>> | PSARC/2006/372/contract-01 >>>>>>>>> | >>>>>>>>> | (amends and supersedes PSARC/2003/322/contract-01 to include >>>>>>>>> | new mdi_* interfaces introduced by PSARC/2006/103; changes >>>>>>>>> | indicated by left-margin change-bars.) >>>>>>>>> >>>>>>>>> 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 (OS/Networking) >>>>>>>>> Department or Group: Solaris I/O Framework >>>>>>>>> Bugtraq Category/SubCategory: kernel/io-multipath >>>>>>>>> | Responsible Manager: Peter Luk >>>>>>>>> >>>>>>>>> 3. The CONSUMER is identified by the following: >>>>>>>>> Product or Bundle: Solaris >>>>>>>>> Consolidation: NWS (Network Storage) >>>>>>>>> Department or Group: SAN Engineering, Network Storage >>>>>>>>> Bugtraq Category/SubCategory: kernel/kernel_driver_fc_ulp_fcp >>>>>>>>> | Responsible Manager: Vince Eberhard >>>>>>>>> >>>>>>>>> 4. The INTERFACES are: >>>>>>>>> >>>>>>>>> FLAG_NOQUEUE Consolidation Private >>>>>>>>> DRIVER_DISABLE Consolidation Private >>>>>>>>> DRIVER_DISABLE_TRANSIENT Consolidation Private >>>>>>>>> mdi_pi_find Consolidation Private >>>>>>>>> mdi_pi_get_client Consolidation Private >>>>>>>>> mdi_pi_disable Consolidation Private >>>>>>>>> mdi_pi_enable Consolidation Private >>>>>>>>> mdi_pi_get_phci Consolidation Private >>>>>>>>> mdi_pi_alloc Consolidation Private >>>>>>>>> mdi_pi_set_phci_private Consolidation Private >>>>>>>>> mdi_pi_online Consolidation Private >>>>>>>>> mdi_pi_free Consolidation Private >>>>>>>>> mdi_pi_offline Consolidation Private >>>>>>>>> mdi_phci_register Consolidation Private >>>>>>>>> mdi_phci_unregister Consolidation Private >>>>>>>>> mdi_prop_free Consolidation Private >>>>>>>>> mdi_prop_remove Consolidation Private >>>>>>>>> mdi_prop_lookup_xxx Consolidation Private >>>>>>>>> mdi_prop_update_xxx Consolidation Private >>>>>>>>> mdi_pi_fault Consolidation Private >>>>>>>>> mdi_component_is_vhci Consolidation Private >>>>>>>>> mdi_component_is_phci Consolidation Private >>>>>>>>> mdi_component_is_client Consolidation Private >>>>>>>>> >>>>>>>>> | mdi_pi_enable_path Consolidation Private | mdi_pi_disable_path Consolidation Private | The SUPPLIER and CONSUMER mutually agree to terminate the contract >>>>>>>>> | the following interfaces from Solaris 11 release and later. | mdi_pi_enable_path Consolidation Private | mdi_pi_disable_path Consolidation Private 5. The ARC controlling these INTERFACES is: >>>>>>>>> PSARC >>>>>>>>> >>>>>>>>> 6. The CASE describing these INTERFACES is: >>>>>>>>> PSARC/1999/647 >>>>>>>>> PSARC 2002/362 >>>>>>>>> PSARC/2003/157 >>>>>>>>> | PSARC/2006/103 >>>>>>>>> >>>>>>>>> 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: >>>>>>>>> >>>>>>>>> _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. >>>>>>>>> >>>>>>>>> _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: >>>>>>>>> The interfaces will evolve in accordance with paragraph 7d above. >>>>>>>>> >>>>>>>>> 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as >>>>>>>>> follows: >>>>>>>>> The SUPPLIER agrees to support the interfaces as specified in >>>>>>>>> the PSARC case. >>>>>>>>> >>>>>>>>> 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as >>>>>>>>> follows: >>>>>>>>> The interfaces are documented as part of the PSARC >>>>>>>>> case materials. >>>>>>>>> >>>>>>>>> 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be >>>>>>>>> tested as follows: >>>>>>>>> Changes to the interface will be tested by the SUPPLIER >>>>>>>>> in addition to the exposure provided by ON. >>>>>>>>> >>>>>>>>> The CONSUMER will be responsible for testing the use of interfaces >>>>>>>>> as described in the PSARC case material which will introduce >>>>>>>>> changes to the interfaces. >>>>>>>>> >>>>>>>>> 14. SUPPLIER and CONSUMER agree that this contract can be terminated as >>>>>>>>> follows: >>>>>>>>> When any interface listed in this contract is rendered obsolete >>>>>>>>> this contract may be terminated as to that interface, subject to >>>>>>>>> the conditions of paragraph 7d above. >>>>>>>>> >>>>>>>>> Otherwise, 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: Peter Luk Date: >>>>>>>>> | For CONSUMER: Vince Eberhard Date: >>>>>>>>> | For ARC: Paul von Behren 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: >>>>>>>>> mdi_pi_enable/disable_path [PSARC/2006/372 Timeout: 06/08/2006] >>>>>>>>> From: >>>>>>>>> Paul Von Behren >>>>>>>>> Date: >>>>>>>>> Thu, 01 Jun 2006 15:06:36 -0700 (PDT) >>>>>>>>> To: >>>>>>>>> PSARC@sac.sfbay.sun.com >>>>>>>>> >>>>>>>>> To: >>>>>>>>> PSARC@sac.sfbay.sun.com >>>>>>>>> CC: >>>>>>>>> Hyon.Kim@Sun.COM >>>>>>>>> >>>>>>>>> >>>>>>>>> Subject: PSARC FastTrack [06/08/2006]: mdi_pi_enable/disable_path >>>>>>>>> >>>>>>>>> >>>>>>>>> Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI >>>>>>>>> This information is Copyright 2006 Sun Microsystems, Inc. >>>>>>>>> 1. Introduction >>>>>>>>> 1.1. Project/Component Working Name: >>>>>>>>> mdi_pi_enable/disable_path >>>>>>>>> 1.2. Name of Document Author/Supplier: >>>>>>>>> Author: Hyon Kim >>>>>>>>> 1.3 Date of This Document: >>>>>>>>> 01 June, 2006 >>>>>>>>> 4. Technical Description >>>>>>>>> >>>>>>>>> Name: Porting mdi_pi_enable/disable_path >>>>>>>>> >>>>>>>>> 1. Proposal Summary >>>>>>>>> >>>>>>>>> PSARC/2006/103 introduced new MDI interfaces to allow a vhci driver to >>>>>>>>> enable/disable a specific path while requesting to deprecate the existing MDI interfaces which lack the components necessary to select the full path to a >>>>>>>>> client device. It also stated that associated libg_fc APIs for enabling/disabling a path to a scsi_vhci device will be deprecated since >>>>>>>>> the original requester never used the interfaces. >>>>>>>>> >>>>>>>>> This fasttrack is to request micro/patch release binding for the MDI >>>>>>>>> new interfaces from PSARC/2006/103. Note that the interfaces that are >>>>>>>>> described to be deprecated in PSARC/2006/103 will be removed on next minor release. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2 Interfaces >>>>>>>>> >>>>>>>>> Exported Interfaces: >>>>>>>>> ---------------- >>>>>>>>> ______________________________________________________________________ >>>>>>>>> | Interface Name | Classification | Comments | >>>>>>>>> ______________________________________________________________________ >>>>>>>>> | | | | >>>>>>>>> | mdi_pi_disable_path | Cons. Private | Disable MPxIO Path | >>>>>>>>> | | | Introduced in | | | | PSARC 2006/103 | | | | | | mdi_pi_enable_path | Cons. Private | Enable MPxIO Path | >>>>>>>>> | | | Introduced in | | | | PSARC 2006/103 | | | | | >>>>>>>>> ______________________________________________________________________ >>>>>>>>> 3 Proposed contract: >>>>>>>>> http://sac.sfbay.sun.com/PSARC/2006/XXX/contract-01.txt >>>>>>>>> >>>>>>>>> (amends and supersedes PSARC/2003/322/contract-01; >>>>>>>>> changes indicated by left-margin change-bars in new version) >>>>>>>>> >>>>>>>>> Earlier contract: >>>>>>>>> http://sac.sfbay.sun.com/PSARC/2003/322/contract-01 >>>>>>>>> 4. Reference Documents: >>>>>>>>> >>>>>>>>> 1. PSARC 1999/647 Multiplexed I/O Framework >>>>>>>>> >>>>>>>>> 2. PSARC 2002/362 MPxIO/scsi_vhci path enable/disable >>>>>>>>> >>>>>>>>> 3. PSARC 2004/626 SNIA Multipath Management API >>>>>>>>> >>>>>>>>> 4. http://sac.sfbay.sun.com/PSARC/1999/647/related_cases.html >>>>>>>>> >>>>>>>>> 5. PSARC 2003/322 Move SAN drivers from ON to NWS >>>>>>>>> 6. PSARC 2006/103 MDI enable/disable of a path >>>>>>>>> >>>>>>>>> >>>>>>>>> 6. Resources and Schedule >>>>>>>>> 6.4. Steering Committee requested information >>>>>>>>> 6.4.1. Consolidation C-team Name: >>>>>>>>> ON >>>>>>>>> 6.5. ARC review type: FastTrack >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> >> >> >> >> >