1. What specifically is the proposal that we are reviewing? - What is the technical content of the project? This is the umbrella case for Ashanti and Zulu. These two projects consist, respectively, of short-term and long-term solutions for the Solaris Zones upgrade problem. The details in this case cover Ashanti in detail, but only the outlines of Zulu. It's expected that a future case will complete Zulu. The Zulu details presented here are just an outline to show future direction. - 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? See the Release Taxonomy in: http://sac.sfbay/BestPractices/release_taxonomy.html This is a "patch/micro" change. - What is the motivation for it, in general as well as specific terms? (Note that not everyone on the ARC will be an expert in the area.) As shipped with Solaris 10 FCS, systems that are configured with non-global zones cannot be upgraded. The relevant tools (including both standard upgrade and Live Upgrade) do not handle non-global zones. - What are the expected benefits for Sun? - By what criteria will you judge its success? Users will be able to upgrade past S10 FCS. 2. Describe how your project changes the user experience, upon installation and during normal operation. Users may already upgrade from any release prior to Solaris 10 to Solaris 10 or later using the existing tools, because releases before S10 don't have Solaris Zones. The Ashanti project will allow the user to upgrade from Solaris 10 FCS to Solaris 10 Update 1. It's a stop-gap effort. Ashanti is available on DVD. It doesn't fit on CDs. CD-based upgrade of a system with non-local zones won't be possible for Update 1. The Zulu project will allow the user to upgrade from Solaris 10 FCS to any future release. 3. What is its plan? The overall Zones Upgrade project has two main components: Ashanti and Zulu. The two share many technical features (such as "scratch zones;" described elsewhere in this project), but have separate goals and delivery plans. Ashanti uses patching to upgrade a system from Solaris 10 FCS to Solaris 10 Update 1. A prototype has been built, and design reviews are underway. Zulu uses regular "fresh-bitted" packages to perform an upgrade from Solaris 10 FCS to any later release. It includes updates to Live Upgrade and other components to make that possible. Design reviews of the various components have been held, and a prototype is underway. There will likely be other ARC cases (besides this one) for Zulu. 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? Shipping Solaris 10 Update 1 depends on this project. This project depends rather strongly on reduced risk in Update 1. The more that is integrated into that release, and the more complex the changes, the more likely it is that this project will run into trouble and cause all of the projects to deliver later. - 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. None. 5. How is the project delivered into the system? - Identify packages, directories, libraries, databases, etc. Changes to (at least): SUNWluu SUNWlur SUNWpkgcmdsu SUNWzoneu SUNWswmt No new packages created. Other changes may be dealt with in a Zulu-related follow-on case. Using Live Upgrade (for Zulu) typically involves: - installing required patches - removing SUNWluu SUNWlur - installing SUNWluu and SUNWlur from the install medium - running lumake and luupgrade - running luactivate - "init 6" 6. Describe the project's hardware platform dependencies. None. 7. System administration - How will the project's deliverables be installed and (re)configured? For Ashanti, the user will upgrade normally using the distribution media (DVD only). There will be documented restrictions on the jumpstart keywords usable. Live Upgrade will not work (it refuses to run). For Zulu, the user can upgrade using standard upgrade or using Live Upgrade. - How will the project's deliverables be uninstalled? N/A - Does it use inetd to start itself? N/A - Does it need installation within any global system tables? N/A - Does it use a naming service such as NIS, NIS+ or LDAP? N/A - 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? N/A - 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)? N/A 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?) The packaging and patching tools write to documented log files and present errors to the user. - What are the project's effects on boot time requirements? N/A - How does the project handle dynamic reconfiguration (DR) events? N/A - What mechanisms are provided for continuous availability of service? Standard upgrade can be interrupted and restarted, though not necessarily reliably in all cases. Live Upgrade is designed to be more reliable. Users may create system images, upgrade them, try them out, and fall back to the previous environment if the upgrade doesn't work as desired. - Does the project call panic()? Explain why these panics cannot be avoided. No. - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? Log files and system console. - How does the project deal with failure and recovery? Ashanti (as with standard upgrade) attempts to detect the required disk space before performing the upgrade. System failure (e.g., actually running out of disk space) tends to cause the upgrade to fail. If a standard upgrade fails, you're probably out of luck; backing up before a standard upgrade is advisable. Live Upgrade allows the user to correct the problem and retry. - Does it ever require reboot? If so, explain why this situation cannot be avoided. You must reboot to start using the new bits after an upgrade. The patch delivered to add scratch zone capabilities does not require a reboot to activate. - 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? N/A - Can it save/restore or checkpoint and recover? Standard upgrade has rudimentary support for checkpoint and recovery. Live Upgrade doesn't need it. If something goes wrong, you can always start over. - Can its files be corrupted by failures? Does it clean up any locks/files after crashes? For standard upgrade: yes, files can be corrupted by failure, and no, there's no clean up for stale locks after a crash. Zulu will add features that make diagnosing and repairing the latter problem easier. 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? Ashanti: system console and log files. Zulu: pkginfo, pkgchk, log files, 'luupgrade' output - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? Ashanti: log output Zulu: new status commands will provide enhanced debug features. - What statistics does the subsystem export, and by what mechanism? None. - What state information is logged? Package and upgrade state are logged to the system console and to known log files. - In principle, would it be possible for a program to tune the activity of your project? No. 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. None. - 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. Projects must highlight information for the following important areas: - What features are newly visible on the network and how are they protected from exploitation (e.g. unauthorized access, eavesdropping) - If the project makes decisions about which users, hosts, services, ... are allowed to access resources it manages, how is the requestor's identity determined and what data is used to determine if the access granted. Also how this data is protected from tampering. - What privileges beyond what a common user (e.g. 'noaccess') can perform does this project require and why those are necessary. - What parts of the project are active upon default install and how it can be turned off. All: N/A This is install; the patient is knocked out and put on an operating table. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? Ashanti: Solaris 10 FCS (only) (The actual upgrade miniroot is loaded from the install medium, and is thus running Solaris 10 Update 1. The system which Ashanti updates, however, is Solaris 10 FCS only.) Zulu: Solaris 7 and up. - Environment variables? Exit status? Signals issued? Signals caught? (See signal(3HEAD).) No new ones. - 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? Existing packaging and zone locking files are used. - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? TBD - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? No. - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? TBD. - Identify and justify the requirement for any static libraries. The packaging and patching tools have many internal static libraries. None are shipped to customers. - 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? Unknown. (There are apparently some known problems with old versions of Java on Solaris 7 FCS. Not sure what the extent of the issue might be.) - Is the project internationalized and localized? Yes. - Is the project compatible with IPV6 interfaces and addresses? Yes. (Doesn't use 'em.) 12. What is its window/desktop operational environment? - Is it ICCCM compliant (ICCCM is the standard protocol for interacting with window managers)? - X properties: Which ones does it depend on? Which ones does it export, and what are their types? - Describe your project's support for User Interface facilities including Help, Undo, Cut/Paste, Drag and Drop, Props, Find, Stop? - How do you respond to property change notification and ICCCM client messages (e.g. Do you respond to "save workspace")? - Which window-system toolkit/desktop does your project depend on? - Can it execute remotely? Is the user aware that the tool is executing remotely? Does it matter? - Which X extensions does it use (e.g. SHM, DGA, Multi-Buffering? (Hint: use "xdpyinfo") - How does it use colormap entries? Can you share them? - Does it handle 24-bit operation? N/A 13. What interfaces does your project import and export? - Please provide a table of imported and exported interfaces, including stability levels. Pay close attention to the classification of these interfaces in the Interface Taxonomy -- e.g., "Standard," "Stable," and "Evolving;" see: http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp Use the following format: Interfaces Imported Interface Classification Comments TBD Interfaces Exported Interface Classification Comments zoneadm -R {un,}mount Contracted Project Private {pkg,patch}{add,rm} Project Private "-O zonelist" lumount -a Project Private libzonecfg Contracted Project Private Jumpstart keywords Unstable See jumpstart.txt - Exported public library APIs and ABIs Protocols (public or private) Drag and Drop ToolTalk Cut/Paste No. - Other interfaces N/A - What other applications should it interoperate with? How will it do so? N/A - Is it "pipeable"? How does it use stdin, stdout, stderr? Not easily. - Explain the significant file formats, names, syntax, and semantics. No new formats. - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? No. - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? No exposed interfaces. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? - Protocols (public or private) - Private ToolTalk usage - Files - Other - Are the interfaces re-entrant? The scratch zone interfaces (libzonecfg) are Project Private and shared between ON and Admin/Install consolidations. 15. Is the interface extensible? How will the interface evolve? - How is versioning handled? - What was the commitment level of the previous version? - Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? - What are the clients over which a change should be managed? - How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? N/A 16. How do the interfaces adapt to a changing world? - What is its relationship with (or difficulties with) multimedia? 3D desktops? Nomadic computers? Storage-less clients? A networked file system model (i.e., a network-wide file manager)? N/A 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? N/A - 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"? Upgrading lots of zones will undoubtedly be slower than updating a system without zones. - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? TBD - Does the application pause for significant amounts of time? Yes. (Though progress bars are available.) Can the user interact with the application while it is performing long-duration tasks? No. - 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? No. - 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? N/A - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? No. - Will it require large files/databases (for example, new fonts)? Packaging maintains its own large database. - 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? No. 19. Please identify any issues that you would like the ARC to address. - Interface classification, deviations from standards, architectural conflicts, release constraints... - Are there issues or related projects that the ARC should advise the appropriate steering committees? Many of the administratively interesting interfaces are classified as Project Private. Giving them greater visibility is probably a worthwhile goal, except that the plans here are unclear. The future of standard upgrade and Live Upgrade is not clear. Standard upgrade will become less usable as more users adopt zones. We should be getting rid of it, if possible, but this means changes elsewhere -- such as preinstalling systems with LU configured, and changing the install-time disk partitioning to handle LU. One thing that is clear is that boot environments (from Live Upgrade) need to become a first-class administrative entity in Solaris, and not dealt with as a "-R" afterthought. 20. Appendices to include - One-Pager. - Prototype specification. - References to other documents. (Place copies in case directory.) Interim (Ashanti) design document: interimUpdateDesign.txt Scratch zones design: scratchzone-design.pdf Jumpstart keywords: jumpstart.txt Final (Zulu) design document: upgradezone-3.3.pdf