1. What specifically is the proposal that we are reviewing? - What is the technical content of the project? The project delivers a framework to use solaris host as a SCSI target platform. The framework consists of a kernel module, stmf, a userland library, libstmf and a management application, stmfadm. 'stmf' divides a SCSI target subsystem into 'Port Providers' and 'LU Providers'. Port Providers are the modules that implement one or more SCSI target ports. Similarly LU providers implement one or more SCSI logical units. Both of these providers are glued together by 'stmf' in such a way that the modules implementing functionality at SCSI level (disk, tape, medium changer etc.) are not required to know about the underlying transport. And the modules implementing the transport protocol (Fibre Channel, iSCSI etc.) are not aware of the SCSI level functionality of the packets they are transporting. 'stmf' hides the details of allocation, providing execution context and cleanup of SCSI commands and associated resources and simplifies the task of writing the SCSI or transport modules. - A high level design diagram is at: http://opensolaris.org/os/project/comstar/files/comstar_overall.jpg - Project one pager is at: http://sac.sfbay/Archives/Projects/2007/20070910_sumit.gupta - The opensolaris project page is at: http://opensolaris.org/os/project/comstar/ - Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", or "micro" change? Its a new product. - If your project is an evolution of a previous project, what changed from one version to another? N/A - What is the motivation for it, in general as well as specific terms? What are the expected benefits for Sun? By what criteria will you judge its success? Please refer to section 3 of the one pager. 2. Describe how your project changes the user experience, upon installation and during normal operation. - What does the user perceive when the system is upgraded from a previous release? No Change. 3. What is its plan? - What is its current status? Has a design review been done? Are there multiple delivery phases? A prototype with QLogic 4G Fibre channel HBAs has been successfully done. Currently the interfaces between different modules are being identified. The project will deliver the kernel framework and the associated library and cli. Initial delivery into solaris will also include a fibre channel port provider and a LU provider implementing SCSI disks as per SBC. A later project will also move the current iSCSI target under this framework. 4. Are there related projects in Sun? - If so, what is the proposal's relationship to their work? Which not-yet- delivered Sun (or non-Sun) projects (libraries, hardware, etc.) does this project depend upon? What other projects, if any, depend on this one? Solaris currently has a SCSI target which only supports iSCSI protocol. This project does not depend upon any component or interfaces exported by the current iSCSI target. It is assumed that a future project will subsume the existing Solaris iSCSI target implementation into this framework. - Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose? If not, please explain the areas of disagreement. The current iSCSI target team approves and acknowledges this project and is involved in the design of this project. 5. How is the project delivered into the system? - Identify packages, directories, libraries, databases, etc. TBD. 6. Describe the project's hardware platform dependencies. None. 7. System administration - How will the project's deliverables be installed and (re)configured? pkgadd - How will the project's deliverables be uninstalled? pkgrm - Does it use inetd to start itself? No - Does it need installation within any global system tables? No - Does it use a naming service such as NIS, NIS+ or LDAP? No - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? N/A - How does this project's administrative mechanisms fit into Sun's system administration strategies? E.g., how does it fit under the Solaris Management Console (SMC) and Web-Based Enterprise Management (WBEM), how does it make use of roles, authorizations and rights profiles? Additionally, how does it provide for administrative audit in support of the Solaris BSM configuration? RBAC will be used. - What tunable parameters are exported? Can they be changed without rebooting the system? Examples include, but are not limited to, entries in /etc/system and ndd(8) parameters. What ranges are appropriate for each tunable? What are the commitment levels associated with each tunable (these are interfaces)? TBD 8. Reliability, Availability, Serviceability (RAS) - Does the project make any material improvement to RAS? N/A - How can users/administrators diagnose failures or determine operational state? (For example, how could a user tell the difference between a failure and very slow performance?) Please refer to observability in section 9. - What are the project's effects on boot time requirements? None. No processing is done until the service is enabled. - How does the project handle dynamic reconfiguration (DR) events? N/A. The framework allows individual providers to register and deregister dynamically. DR will be handled by the providers themselves. - What mechanisms are provided for continuous availability of service? The project allows different logical units to be exported through different target ports to one or multiple initiators across the storage network. - Does the project call panic()? Explain why these panics cannot be avoided. Does not call panic(). - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? The project will use FMA to log ereports related to failures within the framework. - How does the project deal with failure and recovery? The framework allows for each individual Logical unit or Target port to be cleanly offlined and onlined without affecting other components of the system. Please refer to: - Section 4.7, 5.7 and 6.26 of STMF specifications (stmf_if.pdf) - Section 3.27 and 3.30 of libstmf specification. - Section TBD of cli specifications. In addition to the above the project will also allow the entire framework to be shutdown and start through svcadm command. - Does it ever require reboot? If so, explain why this situation cannot be avoided. Does not require reboot. - How does your project deal with network failures (including partition and re- integration)? How do you handle the failure of hardware that your project depends on? See section above on failure and recovery. - Can it save/restore or checkpoint and recover? The project will use smf repository (through libscf interfaces) to save configuration information. Checkpoint and recovery will be provided via smf. - Can its files be corrupted by failures? Does it clean up any locks/files after crashes? No locks are used. For configuration see the section above for smf. 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? The project will provide dtrace probes for the IO and discovery related activity. - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? The project will use FMA to generate events related to failures within the framework. - What statistics does the subsystem export, and by what mechanism? TBD (Likely kstats will be used). - What state information is logged? None. - In principle, would it be possible for a program to tune the activity of your project? Yes. Configuration parameters related to the framework will allowed to be tuned via library interfaces and via CLI (through the library interfaces). 10. What are the security implications of this project? - What security issues do you address in your project? None. - The Solaris BSM configuration carries a Common Criteria (CC) Controlled Access Protection Profile (CAPP) -- Orange Book C2 -- and a Role Based Access Control Protection Profile (RBAC) -- rating, does the addition of your project effect this rating? E.g., does it introduce interfaces that make access or privilege decisions that are not audited, does it introduce removable media support that is not managed by the allocate subsystem, does it provide administration mechanisms that are not audited? No. - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? No. - Please justify the introduction of any (all) new setuid executables. N/A - Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.sfbay/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. The project provides a framework which will not export any out of the box protocols or open any network connections. The clients of the framework (such as iSCSI port provider) might open connections on the network and implement iSCSI protocols. The security of those clients will be addressed in their respective ARC cases. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? Solaris Nevada and SDX releases. - Environment variables? Exit status? Signals issued? Signals caught? (See signal(3HEAD).) During updates to the SMF database, SIGINT, SIGTERM, SIGQUIT are caught. - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? None. - Does it use any "hidden" (filename begins with ".") or temp files? No. - Does it use any locking files? No. - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? Please refer to stmfadm(1M) included with the case materials. - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? N/A - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? The CLI stmfadm, uses: libstmf (this project's library) libc libsysevent libpthreads libscf - Identify and justify the requirement for any static libraries. N/A - Does it depend on kernel features not provided in your packages and not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional kernel loadable modules)? No. - Is your project 64-bit clean/ready? If not, are there any architectural reasons why it would not work in a 64-bit environment? Does it interoperate with 64-bit versions? Yes. - Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a private copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? No. - Is the project internationalized and localized? The CLI is internationalized not localized. - Is the project compatible with IPV6 interfaces and addresses? N/A 12. What is its window/desktop operational environment? N/A 13. What interfaces does your project import and export? Interfaces Imported -------------+--------------------+------------------------- Interface | Classification | Comments -------------+--------------------+------------------------- | | Solaris DDI | Committed | Interfaces defined in section | | 9E and 9F of solaris man pages. Libraries defined | | section 11 of this | Committed | document | | | | Interfaces Exported -------------+--------------------+------------------------- Interface | Classification | Comments -------------+--------------------+------------------------- | | LU Provider | Committed | Implements functionality of | | a SCSI LU. | | Port provider| Committed | Implements functionality of | | a SCSI Target port. | | stmf | Committed | Framework functions for LU | | providers and port providers. | | ioctls for | Project private | Interface between stmf and libstmf | | libstmf | | libstmf | Committed | Library interfaces for managing | | LUN mappings. | | stmfadm | Committed | CLI options. output of | not-an-interface | stmfadm | | | | smf schema | Project private | To store LUN mappings. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? N/A 15. Is the interface extensible? How will the interface evolve? - How is versioning handled? Both the LU provider and Port Provider use version numbers for the data structures they register. - What was the commitment level of the previous version? N/A - Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? Yes. - What are the clients over which a change should be managed? Anybody consuming the LU Provider, Port Provider or libstmf interfaces. 16. How do the interfaces adapt to a changing world? Newer SCSI commands will be implemented by the individual LU providers as per the appropriate SCSI subsection. Similarly newer transport protocols will be implemented by individual port providers. The framework will provide extensions to the SCSI task structure to support different functional areas like OSD and T10 security. 17. Interoperability - If applicable, explain your project's interoperability with the other major implementations in the industry. In particular, does it interoperate with Microsoft's implementation, if one exists? The project will use standard transport protocols to talk to other devices in the storage network. This will make the project interoperable with any initiator (SUN, Microsoft, Linux etc.). Interoperability testing will be performed to make sure there are no issues in this area. - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? None. - Does your project assume that a Solaris-based system must be in control of the primary administrative node? No. 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? While the service is running, it creates worker thread which will consume CPU cycles based on the amount of incoming traffic from the storage network. - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? The project should be able to deliver line rate when a storage platform like x4600 (Thumper) is used as a multipathed storage device with raidz zvols getting exposed as SCSI LUNs. The performance should scale across targets and LUNs e.g. Performance should not degrade when the number of FC ports on the system are increased from 2 to 4 and the number of LUNs are increased from 16 to 32 to 64. - Does the application pause for significant amounts of time? No. Can the user interact with the application while it is performing long-duration tasks? Yes. - What is your project's MT model? How does it use threads internally? How does it expect its client to use threads? If it uses callbacks, can the called entity create a thread and recursively call back? Each incoming scsi task is assigned a worker thread of its own such that the LU providers and Port providers do not have to create threads to process scsi traffic. The framework monitors the providers and times out the tasks if the thread does not return within a predefined duration. Upon timeout, the framework offlines the individual component (and generate the required fault event). - What is the impact on overall system performance? What is the average working set of this component? How much of this is shared/sharable by other apps? The impact on system performance depends upon the incoming traffic from the storage network. - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? Does not wake up periodically. - Will it require large files/databases (for example, new fonts)? No. - Do files, databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? N/A 19. Please identify any issues that you would like the ARC to address. FMA. Any best practices guide in the area of FMA for services. Specially layered services e.g. this project can use zfs (zvols) as the backing store which generate their own FMA events. 20. Appendices to include - A high level design diagram is at: http://opensolaris.org/os/project/comstar/files/comstar_overall.jpg - Project one pager is at: http://sac.sfbay/Archives/Projects/2007/20070910_sumit.gupta - The opensolaris project page is at: http://opensolaris.org/os/project/comstar/ Specs: stmf_if.pdf - STMF specifications listing LU Provider and Port Provider interfaces along with interfaces provided by stmf to the providers. libstmf*.pdf - Library interface specifications. stmfadm.pdf - stmfadm CLI specifications.