PSARC Questions Version 1.22 Approved Oct. 2008 (PSARC/2008/625) The 20 questions outline serves several purposes. One is to present to the ARC in a uniform manner pertinent information about any case. Many of the answers to these questions can be direct and specific references to other case materials (although care must be taken to keep the references current). A second purpose is to allow an ARC member to get a concise overview of the case in an efficient manner. Another purpose is that the 20 questions should provoke thought and questions for project teams unfamiliar with the ARC process, by asking questions about aspects of the project that need be considered. Lastly, the 20 questions serves as a vehicle between the case owner and the project team as an indicator of preparedness. The 20 questions, as do other ARC materials, remain as documentation of the case plan of record. 1. What is the proposal being presented for review? The Solaris 10 Container project provides a solaris10 branded zone which can be used to run a Solaris 10 user-land environment on Solaris Next. * Give an overview of the project and its phase(s). As with the earlier 'solaris8' and 'solaris9' brands, this project delivers the following: - A Branded Container which emulates Solaris 10's user environment, based on the BrandZ infrastructure provided with zones. This brand is called 'solaris10'. Only Solaris 10u8 and beyond will be supported and tested in the zone. Systems running releases earlier than S10u8 must be upgraded before being moved to OpenSolaris. - A mechanism for archiving existing Solaris 10 systems and for redeploying those archives into the branded zone. This process is referred to as p2v and uses the same techniques as the 'solaris8' and 'solaris9' brands. In addition, the following additional capabilities will be provided as compared to the 'solaris8' and 'solaris9' brands. - This brand will be supported on all hardware architectures that run S.next (sun4v, sun4u and x86). The specific platforms, particularly sun4u, will be the same as are certified for S.next. - A "virtual to virtual" or v2v mechanism for archiving existing Solaris 10 native zones and for redeploying those archives into the branded zone on S.next will be provided. The process will be very similar to the existing zone migration [5] feature except that the zone's brand will be changed as part of the process. In addition, if the zone is sparse on S10 it must be converted to a whole-root zone during the migration. This project will integrate in multiple phases. The first phase will provide the basic emulation for running S10u8 in a shared stack zone without delegated ZFS datasets. This first phase is targeted to ship with the OpenSolaris 2010.02 release. The brand on 2010.02 will be positioned as a beta test although the code itself will pass all of the tests in the test plan and be of FCS quality when integrated into ON. Subsequent integrations will add missing features, such as support for exclusive stack zones and delegated ZFS datasets. The full complement of zones features is planned to be available with the brand at the time that Solaris Next is released. * Describe the exposure (OpenSolaris), scope and type of review desired (overview, full case, etc.) The project will integrate into the nevada train of ON for inclusion in OpenSolaris and Solaris Next. This is a full case. * Indicate the release binding requested by the project team. See: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ Minor release binding. * What are the project's deliverables? The project delivers the solaris10 brand along with support for installing the zone using either a S10u8 (or later) system image (p2v) or zone image (v2v). * How does this project align with existing or proposed ARC cases? The relevant cases which this one builds upon are: PSARC 2002/174 Virtualization and Namespace Isolation in Solaris PSARC 2005/471 BrandZ: Support for non-native zones PSARC 2006/030 Zone migration PSARC 2006/366 Stack instances: Exclusive IP stack per zone PSARC 2007/350 Etude: Migration Technology PSARC 2008/125 Etude Part Deux PSARC 2008/766 native zones p2v 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? No, the existing zones administrative commands will be used (zoneadm, zonecfg). * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). N/A * Are there any install time changes? No. 3. What are the exported (defined by your project) and imported (defined by another project that your project then references) interfaces or protocols and their respective stability levels? See: http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ Exported Interfaces Stability ---------------------------------------------------------------------- "solaris10" brand name Committed "SUNWsolaris10" brand template name Committed For the solaris10 brand brand-specific install and attach subcommand options Committed documented in the specification for this case /usr/lib/brand/solaris10 directory Committed SUNWs10brandr, SUNWs10brandu packages Committed /usr/lib/brand/solaris10/version Committed getzoneid(), zone_getattr(), ZONE_ATTR_BRAND and S10_EMUL_VERSION_NUM,attibutes Consolidation Private Imported Interfaces Stability ---------------------------------------------------------------------- brandz[2] Project Private Nevada syscall traps documented Consolidation Private in the specification for this case flar(1m) Evolving Contract included with this case * Is there a versioning scheme in place? Yes, see the specification. * Has the team secured interface contracts where necessary? In progress. * Use an ARC prescribed interface table format. 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. N/A 5. Projects need to be aware of the overall security of the system and how their components affect it. Which parts of this project are critical to the security of the system to avoid such unintended consequences such as unauthorized system entry, unauthorized access to or modification of data, elevation of privilege, denial of service, violation of labeled security, ...? Does this project require elevated privilege? A number of specific policies and practices address various aspects of the security of the system. They are found in appendix 1. Which of these are applicable to this project, and how are they addressed? None. The existing zones security mechanisms are unchanged. 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. Install and boot a solaris10 branded zone. Login to the zone an observe existing behavior as would be seen in a native zone running on Solaris 10. The existing zone's monitoring tools are applicable to solaris10 branded zones. 7. How does the project deal with faults and interruptions? Initialization and restarting? faults & interruptions N/A The existing zones mechanisms are used for initialization and restarting. 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, Branded zones, SunCluster, etc.)? This is a branded zone. As with other types of zones, they can run in a Solaris instance running on a hypervisor. 9. Does this project require administration (i.e., configuration or management)? If so, Yes. * How is the project administered, and what sort of review process has this user interface undergone? The existing zone CLI is used, no new CLI is added. * Is there a means of aggregating management and/or configuration with other related projects? N/A * Does this project deliver its own administration along with the other components, or is this project an administration interface for other projects? The project includes the support for administering the solaris10 branded zones. * Are there any external (to Solaris) management interfaces to consider, or being consumed? No. Projects that require or deliver administrative interfaces are often by their nature security components of the system and should likely address the security question (#5 above, with attention to RBAC and Audit). (See also appendix 2). 10. Have you reviewed the Policies and Best Practices? Are there any exceptions this project needs? See http://www.opensolaris.org/os/community/arc/policies/ http://www.opensolaris.org/os/community/arc/bestpractices/ Yes for review and No for exceptions.