OpenSolaris

OpenSolaris 2009.06 Requirements Document

Document Author: Glynn Foster, v0.1

1. Executive Summary

 With OpenSolaris 2009.06, the focus starts to shift to the enterprise building on the latest successful release. Technology advancements such as Image Packaging System, ZFS Boot, Automated Install and the Distribution Constructor pave the way for new deployments in the enterprise with maximimal ease of use and reliability, whatever the task.

 Two new package repositories, pending and contrib, provide the opportunity of hosting the very latest in best of breed free and open source software in a readily accessible format. A series of contribution, rating and feedback tools for the software contained in those repositories encourages the participatory effect of community support, and ensures that OpenSolaris is the best platform for development and deployment of open source software.

 OpenSolaris will continue to have a re-distributable install image that can be mirrored on download sites around the world. Additionally, package repositories will be mirrored externally for the first time to allow users to connect to the closest repository and install software they need faster than ever.

 With software appliances becoming popular in today's market, the need for OpenSolaris to be flexible enough in a 'shrink to fit' (e.g. JeOS) environment is increasingly important. Significant package refactoring efforts, through package naming, meta-data and contents, will ensure OpenSolaris proves to be an excellent open source platform to develop new appliances, from storage to network.

 OpenSolaris 2009.06 will continue to strive toward key themes for each release - usability and user experience in out of the box configuration, security and auditability in a trusted environment, virtualization, performance and scalability, globalization in a changing world, accessibility for those with assistive needs, while highlighting OpenSolaris' unique technology and strengths.

2. Technology Priorities

 The following section lists out a set of technology priorities for OpenSolaris 2009.06. It by no means attempts to be an exhaustive list of projects for inclusion in this release.

 ==== 2.1 Installation

        INS-1: Continue to advance the area of automated installation in
               OpenSolaris 2009.06 with the addition of a graphical
	       user interface alongside the existing command-line utility
	       for starting the AI web service on a given server.
        INS-2: Provide a command-line utility to convert existing
	       Jumpstart installation profiles to Automated Install ones.
        INS-3: Provide an installation web service hosted on opensolaris.com
	       allowing registered users to connect their machines and
	       install against a selection of profiles.
	INS-4: Allow users to upload their favourite automated installation
	       profiles to share among other users, or register them with
	       the installation web service hosted on opensolaris.com.
        INS-5: The distribution constructor should be capable of creating
	       install images that Automated Install can consume.
        INS-6: Automated Install should support both x86 and SPARC
	       platforms.
        INS-7: Live CD install should support a 'lightweight install' option
	       booting into a simple X session and starting the graphical
	       installer immediately.
        INS-8: The minimum required memory for Live CD install should
               continue to be 512 MB. Both Live CD 'lightweight install' and
	       automated install should work on considerably less, though no
	       required minimum is provided at this time.
        INS-9: GRUB, the graphical boot manager, should support nested
               menu options such that additional options can be displayed
               without reducing simplicity/usability of fewer options.
       INS-10: All installation options, both Live CD and automated
	       install, should provide accessible interfaces for those
	       with disabilities to successfully install OpenSolaris.
       INS-11: The installer should be able to detect if existing platforms
	       are installed on a system (and, preferably be able to read
               common file-systems in use today), along with providing some basic
	       partitioning tools to make the transition to installing
	       OpenSolaris easier.
       INS-12: The installer (both graphical and network based) should be
               able to install additional software from a network repository
               at install time.

2.2 Package Management

        PKG-1: Provide the infrastructure to allow site admins to easily mirror
	       the contents of the package repositories on opensolaris.org
	       without needing to have OpenSolaris (or a package depot)
               installed on their system. Preferably the solution should use
	       the rsync utility for convenience and familiarity.
        PKG-2: Users should be notified when an existing package update
	       requires a reboot of their system, so they may choose to
	       postpone those updates until a more convenient time. Additionally
	       users may decide to lock down a specific version or versions
	       of software from a package update, and should only be notified
	       of package updates that conform to these rules.
        PKG-3: The graphical package manager should notify the user when
	       new packages become available, preferably in a non-intrusive
	       fashion.
        PKG-4: Provide a graphical way to find out which are the most popular
	       packages that users are installing, allowing the user to 
	       rate a package, or submit feedback on that package to a global
	       database.
        PKG-5: Provide a way through a series of package operations for users
	       to see what files within that package have changed between two
	       given versions (or set of versions).
        PKG-6: Provide a way through MIME type association or otherwise, for
	       the user to be able to perform a single-click download and
        PKG-7: The package repository depot server should provide a full
	       search capability through a web browser, and allow users
	       to determine information (name, description, version,
	       contents, license etc) about a given package. Additionally,
	       they should be able to determine which packages are available
	       for a given milestone release and associated updates.
        PKG-8: IPS should support the creation and management of lightweight
	       zones inheriting a core package set up from the global zone,
	       allow the user to additionally install what they need. IPS
	       should search for what it needs locally on the global zone before
	       going to the network ie. if mysql was available in the global
	       zone, it should inherit from that rather than download it again
	       from the package repository.
	PKG-9: IPS should support an image-update across multiple zones as a
	       default option.
       PKG-10: IPS should support the removal of EOL'ed packages from a package
	       repository, either by actual removal or hidden browsing.

2.3 Familiarization

        FAM-1: Package refactoring (name, meta-data and dependencies) should be
	       performed on packages in the /release repository to aid with
	       familiarization for those coming from a different platform, and
	       be consistent to the upstream component name. Where there is a
	       strong relationship between a group of packages, a meta-package
               can be created.
        FAM-2: Provide at least 80% of the top 20 searches to pkg.opensolaris.org
               as new software packages in the network package repository. The
	       top 20% of packages in the /contrib and /pending repositories
	       should be candidates for eventual integration into the /release
	       repository.
        FAM-3: The default boot splash should be a graphical progress
	       indicator, hiding some of the boot messages from the user.
	       The user should have the option, during boot, to dynamically
	       show the boot messages should they wish.
        FAM-4: New boot environments should be associated with a user defined
	       label, for a more consistent and usable experience in the GRUB
	       boot manager. Existing menu options during install and post-install
	       should be simplified where possible for improved usability.

2.4 Hardware Support

        HDW-1: Ensure there is an easy mechanism to install hardware drivers 
	       onto a potentially non-networked base system, when a driver is
	       not installed by default.

2.5 Desktop

        DSK-1: Provide a graphical interface to allow the user to regularly
	       back up their data onto an external drive using ZFS snapshots
	       or mirroring. Users should be able to restore their data from
	       a given back up drive with a simple grahical interface.
        DSK-2: A user should be able to automatically detect printers
	       connected directly through USB, or attached to their network.
	       For each printer, they should be able to configure their
	       printing options with a simplified graphical user interface,
	       along with monitoring any queues to that printer, and their
	       current print job. Preferably this should be a CUPS based solution.
        DSK-3: Provide KDE and Xfce as alternative desktop environments for those
	       wishing to install it.
        DSK-4: Provide an interface to easily switch between virtual consoles and
	       existing desktop sessions through a series of keybindings.
        DSK-5: Compiz should be the default window manager for all capable
	       graphics cards.
        DSK-6: Graphical boot should be the default option for OpenSolaris 2009.04,
	       providing an obvious indication of boot progress. An option to allow
	       advanced users to read boot messages with a simple key press toggle.
        DSK-7: Fast reboot should be the default option where possible. The system
	       should try to detect whether drivers support quiesce(9E) or not
	       and judge whether the environment is suitable for a fast reboot
	       appropriately.

2.6 Network

        NET-1: Provide network virtualization and resource control, allowing the creation
	       of a virtual stack that can be assigned its own priority and bandwidth
	       on a shared NIC ie. Crossbow.
        NET-2: Provide a graphical interface to allow users to share out their
	       network connection to others ie. they connect through a wired connection,
	       and share out over wireless with a user set network encryption key.
	       Additionally, users should be able to set predefined conditions for this
	       network share like bandwidth allocation or CPU throttling.

2.7 Storage

        STO-1: Provide a iSCSI port provider adding support for an iSCSI transport
	       option for COMSTAR.

2.8 Documentation

        DOC-1: Provide a wiki on opensolaris.com to host documentation for the OpenSolaris
	       distribution, allowing users to be able to provide feedback on existing
	       howtos based on their experiences.

2.9 Power Management

        PWR-1: Provide a tickless kernel architecture to OpenSolaris ensuring that
	       all systems reduce their power consumption during idle periods, and
	       power down the CPU appropriately.

2.10 Developer Stack

        DEV-1: Provide the latest versions of the popular GNU compiler stack used
	       in common free software communities today, including autotools and scons.
	       Versions should be decided on feedback from the pkgfactory project,
	       and other consumers of that software.
        DEV-2: Provide Bazaar and Git in the package repository, 2 of the more popular
               source code management tools used in the open source communities.
	DEV-3: Provide the popular JavaFX stack in the network package repository.

2.11 Web Stack

        WEB-1: Provide a set of the 10 most popular web development frameworks
	       eg. Rails, Django, in the network package repository.
        WEB-2: Provide a set of the 10 most popular content management frameworks
	       eg. Zope, Plone, Joomla!, Drupal, SilverStripe in the network
	       package repository.
        WEB-3: Provide a set of the 5 most popular wiki frameworks eg. TWiki, JSPWiki,
	       MediaWiki, Moin Moin in the network package repository.
        WEB-4: Provide a set of the 3 most popular blogging frameworks
	       eg. Wordpress, Movable Type, Roller in the network package repository.
        WEB-5: Provide a set of 4 of the most popular database frameworks used by
	       various web applications eg. MySQL, postgresql, sqlite, drizzle in the network
	       repository.
        WEB-6: For at least 70% of the frameworks added, provide an initial set of
               DTrace probes to allow developers to profile their web applications
               in realtime.
        WEB-7: For at last 40% of the frameworks added, provide an optimized experience
	       on OpenSolaris eg. optimized binaries, SMF service support
        WEB-8: For each framework added to the network package repository, provide the
               shortest time to startup possible, starting them using a default
	       configuration, default database, and port so that the user can see the
	       results of their software addition immediately.

2.12 Distribution Construction

        CON-1: Provide infrastructure to easily create virtual images for VirtualBox.
        CON-2: The distribution constructor should allow the creation of images to
	       be used in co-ordination with the automated install web service.
        CON-3: The distribution constructor should have a graphical interface to
	       accompany the command-line interface.

2.13 Device Detection

        DDU-1: Provide a means to submit the collected information securely to a
	       centralized database, along with any additional reports from the user
               of whether certain devices work eg. sound. The user should get a
               confirmation thanking them for their submission, stating that it has
               been an invaluable contribution to the project, with a link to where
               their report is available to view anonymously. 
        DDU-2: The database should have a public front-end, preferably on opensolaris.org/com,
               allowing users to anonymously search entries that have been submitted, along
               with being able to get a series of reports based on the raw data eg. top 10
               wireless drivers that are supported, unsupported, or known to work. Additionally,
               the interface should allow the users to comment as appropriate on various 
               platforms with workarounds or otherwise that are available.