direct link

Update Center 2.0 Requirements

This document lists the requirements of packaging and update features as they apply to layered or software infrastructure (middleware) components.

Update Center 2.0 Themes

Update Center 2.0 will focus on few key areas. Refer to this wiki to learn more about the themes.

Actors in Scope

Actor	Description
Community Lead	People leading and overseeing open source projects
Community Release Manager	People responsible for making users of community binaries aware of new and updated community binaries. Similar to Product Marketing Manager, but oriented toward the needs of a community as compared to the needs of people interested in commercially available services.
Product Manager	People maximizing the opportunity to present pay for services to users of update tooling. For example, people that would help specify grouping of technologies for installation and updating. These people would also help specify cross-promotion of services in update tool GUIs and installation GUIs. (Similar to Eduardo's notion of an Update Center GUI being akin to iTunes where many different offerings are presented to users in the context of a core service - music and media management).
Project Developer	People developing and sustaining open source and/or commercial projects consisting of components that will be packaged, distributed, installed and updated.
Package Maintainer	People creating and maintaining packages. Also known as package developers.
Repository Maintainer	People managing server side repositories of binary package distributions. This role manages the views of the binaries that are presented to client tools and administrators.
Distribution Assembler	People creating install applications, assembling installable distributions. Sometimes this role is split into two organizations: Install application developers and release engineering teams.
Administrator	Specialized administrators of middleware installation images. A developer plays the role of an administrator when he manages an installation image.
Integrator	Similar to administrators of installation images, but with the additional responsibility to embed an installation image in a greater product offering or service. Applies to OEMs, ISVs and enterprise projects that combine a collection of software components into a discernible product or service.

Overall Requirements

Requirements that are unique to the software infrastructure or middleware space as compared to requirements of an OS are are highlighted in red.

#	Title	Description	Priority	Response
Overall-1	Uniform, Multi-OS platform packaging approach
Overall-1.1	Provide a multi-OS platform packaging approach to be used by SWI components for the following operating systems: * Solaris 10 and 9 * OpenSolaris Binary Distro * Windows XP, Vista, and 2003 Server * Popular Linux distributions on x86 systems including: * Ubuntu * Fedora * Red Hat Enterprise * Debian * SuSE * Mac OS * AIX * HP-UX	By default, components will be delivered in uniform, multi-OS platform package format. Decision Tree for Multi-platform Packaging Direction (rationale for pursuing a multi-platform packaging direction)	P1	Partial Yes. Certification of the UC client and repository server infrastructure will be performed on a subset of these OS platforms. Minimally, the UC infrastructure will be certified on: * Solaris (SPARC and x86) - UC Client and Server * OpenSolaris (SPARC and x86) - UC Client and Server * Windows (x86) - Client and Server * Ubuntu (x86) - Client and Server (Ubuntu on SPARC is an open question) * Mac OS (x86 and PowerPC) - Client Only * AIX Linux: We need to ensure that the IPS client and server can run on most any recent version of popular Linux distributions. For example: Fedora, Ubuntu, Red Hat Enterprise, Debian, etc. Client vs Server Support: Ideally, we should not deliver only client-side support because we want to promote the notion of other projects playing with and running their own repositories. Since the majority of developers use Windows, it follows that some number of them would want to experiment with and perhaps even host their own repositories. To do so, they would need to run the server side IPS software. Easy to Port: Since the UC 2.x infrastructure will be designed and implemented to be capable of running on a variety of OS and processor combinations and the method of building and certifying for the UC 2.x certified platforms will be published as part of the UC open source project, other projects interested in realizing UC 2.x support on other OS/processor combinations will be able to rebuild and certify on their own.
Overall-1.2	Ease the generation of OS-specific format packages	As the need arises, components will also be delivered in OS-specific package formats in addition to the multi-platform packaging format identified by this project.	P2	No. This feature is not inherently tied to the UC 2.x project. Given that many projects have an interest in this capability, solutions will likely arise through other projects.
Overall-2	Multiple Installation and User-based Installation
Overall-2.1	Ability to install multiple, completely distinct installation images on the same OS instance.	Including distinct package databases. Refer to Multi-install and User-based Install Strategy	P1	Yes
Overall-2.2	Ability to install and manage packages as non-OS system administrators	See Multi-install strategy document for details.	P1	Yes
Overall-2.3	Ability to install and manage packages as OS system administrators.	Need to make sure reasonable things happen when user is running as root or the OS sytem adminimstrator	P1	Yes.
Overall-3	Open Source Ready
Overall-3.1	Packaging, repository and update technology must be open source.	Which license types must apply?	P1	Yes
Overall-3.2	Aligned with "all Java" interests of Sun sponsored Java open source projects (such as GlassFish)	Implies that the solution should be implemented in Java.	P2	No. Parts of UC 2.x are non-Java (e.g. IPS is written in Python, but most of it is portable.
Overall-4	Build vs Reuse and Extend
Overall-4.1	Emphasis must be on selecting and possibly enhancing an existing open source format and associated tools that meet these requirements.		P1	Yes, reusing IPS and other technologies.
Overall-5	SMI and Java Alignment
Overall-5.1	Compatibility with SysNet Update Connection	For example, the Aduva Knowledge Generation Machine must be capable of consulting the repositories deployed in the technology defined in this project for update and package information. Much as the KGM is capable of mining information from Solaris SVR4 packages and Solaris patches and RPM and DEB repositories. Generally, the outlook for SysNet integration is that the multi-platform repository and package management client tooling direction specified in this project will provide a lightweight solution in the near-term that can be used by open source projects and commercial products. Over time, as SysNet update center technologies support multiple OS platforms, the SysNet infrastructure may gradually supplant some of the lightweight technologies and in some cases complement these lightweight technologies. It is expected that the underlying, multi-platform package format and associated repository technologies will be carried forward even as SysNet technologies and services are combined with these underpinnings.	P1	Yes, indirectly. The outlook is promising given that OpenSolaris is spearheading the IPS package and repository infrastructure. Technologies that presumably would be supported by Sysnet's multi-system update management strategy. The UC 2.x project intends to capitalize on the SysNet/OpenSolaris IPS integration as it arises.
Overall-5.2	Alignment with Solaris packaging strategy	Best effort is required to align with emerging Solaris packaging and update strategy. A time frame must be set by which this project must make a call as to the direction for layered software - with or without Solaris having made a decision.	P1	Yes, we're reusing OpenSolaris' IPS package format.
Overall-5.3	Alignment with GlassFish Application Server	Need to rationalize the approach for layered software in general with the GlassFish add-on module and update center approach. If different technologies are ultimately used for these two domains, then we must have a solid reason for the divergence.	P1	Yes. UC 2.x will suit GlassFish project needs.
Overall-5.4	Alignment with JSR-277, Java Module System	This technology is addressing some overlapping requirements. It is being included in Java SE 7.	P2	No. We're not using the emerging JSR-277 specification, but JSR-277 modules could be delivered within IPS packages.
Overall-5.5	Alignment with JDesktop Integration Components	Application Platform SDK uses this technology to establish an update checking and notification task in the desktop task tray. This technology is being included in Java SE 6.	P2	TBD. UC 2.x might reuse JDIC as appropriate to promote cross-platform code for Start/Applications menu and task tray integration.
Overall-5.6	Alignment with NetBeans direction	A desired result, but not an absolute requirement. The App Server add-on module and update center approach is partially based on the NetBeans module specification implemented in NB 5.5.	P2	TBD. UC 2.x is not based on NetBeans Module (NBM) format, but it is conceivable that IPS packages could be integrated with the NetBeans Plug-in Manager through a yet to be developed IPS provider that would hook into the NetBeans 6.x Auto Update Center's backend SPI.

Community Lead / Product Manager

#	Title	Description	Priority	Response
CL-1	Report on Usage
CL-1.1	Collect and report data on unique active installations	Enables community and product groups to understand popularity and uptake of certain technologies. "active" means not only has a user downloaded and installed a technology, but they have used it on an ongoing basis. Unique does not imply each user has to identify themselves. The service must still be capable of being anonymous, but an installation itself may have a unique ID associated with it beyond network address such that distinct installations can be identified.	P1	Yes. At a minimum, usage reporting techniques used in UC 1.x will be carried forward. This feature set will be enhanced with the new user and product registration capabilities being implemented in UC 1.x and also carried forward to UC 2.x.
CL-1.2	Collect and report package usage information	Enables communities and product groups to understand popularity and uptake of certain technologies. Differs from CL-1.1 in that this requirements pertains to each package that has been installed originally, updated and added after initial installation. Helps provide basis for "popular package" information (perhaps star ratings) to community members.	P1	Yes, shared interest with OpenSolaris.
CL-1.3	Allow users to write reviews for downloads and give ratings		P3	No, but of interest to support in future release.
CL-1.4	Capability to present banner ads	Enables Community Lead to present relevant and non-intrusive banner ads	P1	Yes, via RSS-based context feeds.

Community Release Manager Use Cases / Product Manager

#	Title	Description	Priority	Response
CE-1	Specify Presentation of Packages
CE-1.1	Control number and role of community managed repositories	Respond to needs of community by lending organization to how binaries are presented to administrators	P1	Yes. Reusing IPS-based repository infrastructure and providing repo management strategy and guidelines.
CE-1.2	Specify groupings of related packages	To be made visible within installers, through repositories and through client side update tools. Groupings of packages may be driven by a number of factors.	P?	TBD. Although package maintainers will control how their packages are named and made visible at the very basic level, e.g. "pkg install glassfish2" represents the fact that a package maintainer made available a package named "glassfish2", there might be a need for release and product managers to represent one or more packages as one or more features that are made readily visible to users via the UC GUI and/or CLI. This downstream capability should not change the package groupings and dependencies defined by the package maintainers. Design of the UC GUI will help drive a better understanding of the requirements concerning adding metadata downstream of package creation that helps present a feature view of packages.
CE-1.3	Specify content of installable from scratch distros and pre-configured, ready-to-run images		P1	Yes, to installable from scratch distros via OpenInstaller and IPS integration. No, to preconfigured images. We will provide experimental examples of preconfigured images, but we won't be delivering RR quality support for them in 2.0. Likely a close follow-on feature set.
CE-2	Specify Update GUI Content
CE-2.1	Specify promotions and news for delivery through update client GUI tooling		P1	Yes.

Project Developer Use Cases

#	Title	Description	Priority	Response
PD-1	Applications Supported
PD-1.1	Comprehensive support for traditional OS hosted applications	The design center is traditional file based installations I.e. applications that are hosted directly on an OS.	P1	Yes
PD-1.2	Sufficient support for Web/J2EE based applications	While the design center is traditional file based applications, the infrastructure must support installation, configuration, and basic deployment operations for web and J2EE based applications (details TBD)	P1	Yes. See PM-8.2.
PD-2	???
PD-2.1	To what extent does packaging affect project developers?	Certainly to the extent that a developer sustaining a technology will need a straightforward means to deliver or convey the changes. Additionally, there might be best practices that the sustaining developer should bear in mind when delivering a change.	P?	Need clarity around the requirement.

Package Maintainer Use Cases

#	Title	Description	Priority
PM-1	Deliver New Packages
PM-1.1	Guidelines and tools to generate packages	Preferably, the tools would convey and promote guidelines and best practices as much as feasible. See existing Packaging Best Practices document for examples.	P1	Yes, a shared interest with OpenSolaris.
PM-1.2	Easily learn of other packages on which to depend		P1	Yes, a shared interest with OpenSolaris. e.g. Ability to browse content of package repositories.
PM-1.3	Specify dependencies on other packages	Refer to the common capabilities already supported by formats such as RPM and DEB.	P1	Yes
PM-1.4	Specify dependencies on files not necessarily delivered by packages	For example, specifying a dependency on a file expected to be delivered outside the product or in an OS.	P1	TBD. What is IPS' outlook?
PM-1.5	Specify relative and default installation locations for files		P1	Yes, shared interest with OpenSolaris.
PM-2	Deliver Updated Packages
PM-2.1	Deliver cumulative updates	Maintainer is able to specify and deliver and accumulation of updates for a package.	P1	Yes, shared interest with OpenSolaris.
PM-2.2	Enable user to pick and choose specific updates	Without taking the accumulation of updates made to date to a package.	P2	Probably not. UC 2.x will be offering whatever IPS supports in this regard.
PM-2.3	Deliver updates in form of complete/whole packages		P1	Yes, shared interest with OpenSolaris.
PM-2.4	Deliver updates in sparse packages		P2	Yes, a fundamental feature of IPS.
PM-2.5	Deliver change at the file level	See Conary for an example. It is capable of delivering and applying changes at the file level.	P2	Yes, a fundamental feature of IPS.
PM-2.6	Deliver transportable changes	Connection to a live repository need not be necessary in order to obtain, transport and apply updates.	P1	Yes, shared interest with OpenSolaris.
PM-2.7	Preserve administrator customizations to files across updates	For editable files, automatically preserve pre-update form of the file, perform best effort 3-way merge using original/ancestor, customized and updated files.	P1	IPS has basic support here (a couple flavors of preserve), but 3-way merge is not one of them.
PM-2.8	Deliver updates in a compressed format	To reduce download size. Also support storing of updates in compressed format in local disk caches if any.	P1	Yes, IPS appears to deliver this support.
PM-3	Accommodate Platform-specific Content
PM-3.1	Ensure that OS- and OS/processor-specific content can be delivered within packages.		P1	Yes. IPS tags at the file level enables package maintainers to associate OS and processor architecture information and IPS client facilities enable installers to filter content based on tag data. Partially shared interest with Solaris. They care about the processor arch, but not much focus on OS specific content -- at least not that we've seen. e.g. Hosting content for different OS platforms in the same package and/or repository.
PM-3.2	Readily distinguish instances of same named package built for different OS or OS/processor platforms		P1	Yes, shared interest with OpenSolaris.
PM-4	Embed Packages of Other Types
PM-4.1	Declare embedded packages of certain predefined/known types and to leverage pre-built functions to act on those types	Are WAR files an example? We need practical examples	P2	Yes, but exact approach is TBD.
PM-5	Advanced Packaging Techniques
PM-5.1	Install and manage multiple versions of same named package		P1	Yes, shared interest with OpenSolaris.
PM-5.2	Implement pre- and post-install and remove scripts	Need to define some practical boundaries here.	P1	No, but IPS has an "actions" feature that may be used to address package-specific operations during package install.
PM-5.3	Create package groups	To enable named collections of related packages that may be referenced by name through client package management tools. e.g. apt-get webserver	P1	Yes, shared interest with OpenSolaris.
PM-5.4	List content and metadata of a package	Both for installed and not yet installed packages		Yes, shared interest with OpenSolaris.
PM-5.5	Verify correctness/integrity of a package	Both for installed and not yet installed packages		Yes, shared interest with OpenSolaris.
PM-6	Deliver OS-Native Packages As Necessary
PM-6.1	Generate OS-specific package formats at will	This is a requirement that could be satisfied over time.	P2	No.
PM-7	Security
PM-7.1	Sign packages		P1	TBD, shared interest with OpenSolaris. What is IPS' approach?
PM-8	Configuration
PM-8.1	Clear separation between installation and configuration	The packaging and update mechanism architecture must support a clear and distinct separation between installation and configuration without intermingling the two.	P1	Yes, shared interest with OpenSolaris.
PM-8.2	Well defined API to trigger configuration logic (configurators) after installation		P1	Yes, but only to the extent of addressing configuration directly after or during package install time. This effort will not result in an overall configuration solution for applications. It will only address commonly expected configuration during or immediately following package install time. e.g. Creation of desktop Start/Applications entries as a result of installing a package.
PM-8.3	Supports silent configurators as well as those that require interaction with the user.		P1	Yes

Repository Maintainer Use Cases

#	Title	Description	Priority
RM-1	Organize Packages in Repositories
RM-1.1	Easily establish repositories		P1	Yes, shared interest with OpenSolaris
RM-1.2	Combine selected packages in arbitrary groupings	For example, packages will likely be grouped according to stability levels, source of the packages, functional associations, etc.	P1	Yes, shared interest with OpenSolaris
RM-1.3	Present views of repositories to client update tools		P1	Yes, shared interest with OpenSolaris
RM-1.4	Easily establish mirror repositories		P1	TBD, shared interest with OpenSolaris.
RM-1.5	Include up to at least 1,000 packages in each repository		P1	Yes, shared interest with OpenSolaris
RM-2	Security
RM-2.1	Ensure package management clients can validate the identity of repositories	So as to avoid man in the middle attacks	P1	Yes, shared interest with OpenSolaris
RM-2.2	Encrypt communication between update clients and repository servers	Defer to Sun Update Connection tooling for this level of security	P2	TBD, shared interest with OpenSolaris
RM-2.3	Authorize access to repository content	Defer to Sun Update Connection for this level of security	P2	TBD, depends on business model for controlling access to updates.

Distribution Assembler Use Cases

#	Title	Description	Priority	Response
DA-1	General
DA-1.1	Minimize distribution size of bootstrap install image	Since the packaging and basic update technologies are expected to be used by relatively small-scale distributions. e.g. 10's of MB and upward, the distirbution size of the bootstrap install image must be relatively small. As a guideline, a maximum size of 5MB for the bootstrap image is desired. This target size excludes the size of a JRE if a JRE is required by the selected technology. Requirements for the installed size of the bootstrap functions are not yet defined.	P1	Yes
DA-1.2	Minimize external dependencies of bootstrap install image	Do not require administrators to install extra software apart from what is contained in the bootstrap install image in order to operate the basic package management and update tooling.	P1	Partial. Python and Java are required. Whenever Python is not typically preinstalled on a target OS, the UC bootstrap client packages will contain an embedded copy of Python. A suitable version of Java will be a prerequisite for use of UC. The UC bootstrap client will not include Java unless the distribution of which it is a part chooses to carry Java as a convenience to users. (The Java EE and Java Application Platform SDKs provide downloads with and without a bundled copy of Java).
DA-2	Create Installable Distributions
DA-2.1	Easily create installable, minimum bootstrap images from which basic package management tools can be launched	There may be zero to many component packages initially installed. An administrator may use the installed package management tools to add packages to the minimum installation.	P1	Yes
DA-3	Create Pre-installed Images
DA-3.1	Easily create pre-installed and pre-configured images that can be transported to another compatible system and used immediately with no modifications to the package database	To the extent necessary, component configurations may need to be customized for the target host and network environment. However, this level of customization is outside the scope of the packaging system. See presentation on Soft Appliances and pre-installed images.	P2	No. Only experimental examples.
DA-4	Scaling
DA-4.1	Include hundreds of packages in single distro.	Ensure that packaging and update infrastructure can support the inclusion of scores to hundreds of packages in each distribution and install image.	P1	Yes, shared interest with OpenSolaris

Administrator Use Cases

#	Title	Description	Priority	Response
ADM-1	General
ADM-1.1	Minimize UIs required for package management functions.	Preferably, a single GUI and a single CLI should be all that are needed to carry out basic package management and update operations.	P1	Yes, the IPS pkg client CLI includes both local disconnected and network repository-based package and update operations. We expect that CLI operations will be addressed through the IPS pkg CLI. We don't expect to add another CLI. A single GUI should be sufficient as well. However, when managing unbundled distros on OpenSolaris where an IPS-capable package manager GUI will be available, it is not yet clear that the bundled package manager will be sufficient to manage unbundled IPS-based distros made available for OpenSolaris. It is certainly desirable to reuse the OpenSolaris GUI, but it is unclear if doing so will be feasible.
ADM-1.2	Standalone package management tool must be visible through the desktop applications menus		P1	Yes, shared requirement with OpenSolaris
ADM-1.3	Headless systems with CLI only	Virtually all of the basic package management operations must be available through CLI mode.	P1	Yes, shared requirement with OpenSolaris
ADM-1.4	Interactive response times	Less than 3 seconds response time for the following operations when 100 packages exist in an installation: * List installed packages * Search for package by name * Others...	P1	Yes, shared interest with OpenSolaris.
ADM-1.5	High quality error messages	All error/warning/informational messages must be specific, precise, explicit and constructive.	P1	Yes, applies to both GUI and CLI
ADM-1.6	Robust logging support	Relevant information should be logged to a log file	P1	Yes
ADM-1.7	Audit trail	An audit trail of installations should be provided. This may have information like module name, version number, date installed, etc.	P2	TBD. Need to determine extent to which IPS is providing this feature set.
ADM-1.8	Sufficient busy/progress feedback.	In the install/update GUI, busy feedback should be provided for any operation that takes longer than 1 second. In the GUI and CLI progress feedback should be provided for any operation that takes longer than 10 seconds.	P1	Yes
ADM-1.9	Ease of use: CLI and GUI should be attractive, efficient, and easy to use.		P1	Yes
ADM-1.10	Desktop Integration: Start Menu	Enable packages to populate start menu. Handle multiple instances of a particular version of the product installed on the system at the same time	P1	Yes, shared interest with OpenSolaris
ADM-3.5	Add: Where applicable installer should automatically detect dependencies already installed on the system like J2SE.		P1	Yes
ADM-2	Obtain Installable Distributions and Images
ADM-2.1	Obtain installable from scratch distribution of varying sizes.	"Installable from scratch" means that all of the basic tools required to manage and update the installed image are included in the distribution. The extent of packages included in a distribution versus those the administrator chooses to downloaded and install after the fact will vary. In some cases, the minimal install image, basically a small footprint bootstrap environment, will be installed and the administrator will select which additional packages to retrieve and install.	P1	Yes
ADM-2.2	Obtain a pre-assembled image		P1	No, project will provide experimental examples, but not a complete solution.
ADM-2.3	Verify authenticity or origin of obtained distributions		P1	Yes
ADM-3	Perform an Initial Installation
ADM-3.1	Install a set or subset of interrelated packages making up a distribution, from local media	The assumption here is that network access is restricted or not present on a given node (e.g. for security purposes).	P1	Yes
ADM-3.2	Install a set or subset of interrelated packages making up a distribution, from remote media	Here, the content to be installed is not available locally, only from a network-accessible repository.	P?	Needs clarification.
ADM-3.3	Install a pre-assembled image		P1	No, see above.
ADM-3.3	Understand privacy aspects of software being installed	The administrator must understand if any information will be transmitted back to Sun. They must be notified, they must consent to such transmissions, and it must be easy to "opt out", all of which must be present during the interactive initial installation.	P1	Yes, carry over approach from UC 1.x
ADM-3.4	Understand external dependencies of a distribution and/or preassembled image	Ability to be notified of requirements of the underlying OS or other external components by the obtained distribution or pre-assembled image	P1	Yes
ADM-3.5	Minimize external dependencies for bootstrap install image.	Don't force administrators to install pre-requisites in order to operate a basic install image. Attempt to keep external requirements for the operation of the basic bootstrap install image to those dependencies that are typically already found within the underlying OS environments. When target OS' don't typically contain required dependencies of a bootstrap install image, embed these dependencies in the bootstrap install image.	P1	Yes
ADM-4	Learn of Updates and New Packages Using Client Side Tools
ADM-4.1	During initial installation	Need clarification.	P?	Needs clarification.
ADM-4.2	Automatic desktop notification of updates and new components		P1	Yes
ADM-4.3	During application startup or other application-specific activity	For example, accessing an administrative console of an application should make the administrator aware of available updates.	P1	Basic API will be present, but the application or product needs to take advantage of the API.
ADM-4.4	Become aware of and obtain updates and new packages from multiple repositories		P1	Yes, shared requirement with OpenSolaris
ADM-4.4.1	View summary of changes in a particular version of a package such that you can make an informed decision about whether you'd like to apply it.	* See * Add link to patch information supplied by SunSolve.	P1	Yes, shared requirement with OpenSolaris
ADM-4.5	Easily view groupings of related packages	Likely, the groupings will be defined by the repository maintainers	P1	Yes
ADM-4.6	Learn of updates via means other than through local, client side tools	Out of scope of this project. For example, by browsing the community or Sun web sites.	P3	No
ADM-4.7	Understand privacy aspects of learning of updates	The administrator must understand if any information will be transmitted back to Sun. They must be notified, they must consent to such transmissions, and it must be easy to "opt out", all of which must be present at least once in the course of using client-side update tools (E.g. the first time such a tool is used) See ADM-3.3.	P1	Yes, see above
ADM-4.8	Send RSS feeds to update/install clients	To promote blogs/articles/screencasts to our users.	P2	Yes, to the extent that cross-promotion support is agreed to for UC 2.0.
ADM-4.9	Distinguish types of updates and provide appropriate notifications via desktop tray icon	For example: Bug Fix Update, Security Update, New Feature Update	P3	Yes, to notifying of updates overall. TBD on classification. Shared interest with OpenSolaris
ADM-4.10	Elegant desktop notification for multi-install	The desktop notification UI must elegantly scale to support multiple installations of applications/distributions. For example if the user has 6 copies of a distribution installed on the system they should not have 6 individual notification icons. (DT001)	P1	Yes
ADM-5	Search for packages of interest
ADM-5.1	Search for availability of packages by name	Via CLI and GUI, be able to search for packages of interest. e.g. Administrator wants to install "PHP".	P1	Yes, shared interest with OpenSolaris
ADM-6	Install Updates and New Packages
ADM-6.1	Trigger installation from "advertised" services (e.g. icons which install new applications)		P1	Yes, but degree of integrated experience is TBD. For example, degrees include: 1) cross-link, 2) link and enable direct download of new distros, 3) 2) plus seamless install integration
ADM-6.2	Carry out installation through explicit invocation of package management tools
ADM-6.3	Obtain a transportable archive of an update and install without network access	Cannot always depend on a live connection to a repository.	P1	Yes
ADM-6.4	Apply changes selectively rather than being forced to apply cumulative changes	Some administrators don't want to be forced to apply the cumulative changes affecting installed packages. They may want only the fix for a specific problem.	P3	No. OpenSolaris is keen on avoiding what they refer to as "dim sum" patching. We are expecting that whatever degree of flexibility required of OpenSolaris users and supported in IPS will meet the needs of unbundled distro users.
ADM-6.5	Remove (Undo) an update applied to a package	The ability to remove an individual update applied to a discrete package, returning the system to the state it was in prior to application of the updated package. This is a necessary (but not sufficient) function in order to support a higher-level rollback of a product update/upgrade to a previous operational state. It is assumed that a higher-level rollback requires actions outside of the scope of packaging, to affect a complete reversal of a product- or stack-wide update. Possible rollback implementation scenarios are detailed here .	P1	Yes, at least at a basic level.
ADM-6.6	Remove (Undo) an update applied to a package, with limited or no access to media	In many cases, access to the repository from which the update was installed is no longer available. The removal of discrete updates must not require network access to the repository.	P1	Yes.
ADM-6.7	Verify authenticity or source of new and updated packages		P1	Yes, shared interest with OpenSolaris
ADM-6.8	Smart download restart	Sudden loss of connectivity should not require full download to start over. Downloading should be smart enough to pick up where it left off.	P2	No, unless IPS implements the feature
ADM-6.9	One click download/install.	Ability to initiate a download and install of an installable distribution with one click off of a web page (using JNLP for example)	P2	No, depends on OpenInstaller or other initial install frameworks
ADM-7	Copy an Installation
ADM-7.1	Copy an installed image from one system to another	Similar to DA-2.1. For example, as part of the process of promoting a tested installation from a development or test system to a pre-production staging system and eventually onto a production system. To the extent necessary, component configurations may need to be customized for the target host and network environment. However, this aspect of customization is outside the scope of the packaging system.	P2	No, UC 2.x will deliver experimental examples, but won't productive this feature set.
ADM-8	Obtain a New Version of a Distribution
ADM-8.1	Side-by-side installations	Support frequent cases in which new versions of installations are intended to co-exist on the same OS instance.	P1	Yes
ADM-9	Upgrade to a New Version of a Distribution
ADM-9.1	Help facilitate an in-place upgrade of an installation	An "in-place" upgrade is one in which at the end of the upgrade process the same installation path contained the upgraded installation. This results does not have to imply that each package is upgraded in place. The mechanism used to achieve this result might perform a backup of the current installation, install a new image and then upgrade the configurations. The packaging infrastructure will likely play a supporting role for in-place upgrades, but the overall responsibility for orchestrating an in-place upgrade probably rests with higher-level tooling.	P?	No, update in place will be supported, but upgrade in place will be owned by product teams.
ADM-9.2	Help facilitate a side-by-side upgrade of an installation	In many cases administrators either do not trust an "in-place" upgrade procedure or wish to preserve their existing installation when installing a new version of an offering.	P1	Yes
ADM-9.3	Help facilitate rollback of install image-wide upgrade failure	In contrast to the removal of an individual update applied to a singular package, removal or rollback of an installation-wide upgrade is more involved and can span the entire depth of a dependency tree of a stack of components. It is clear that there is value in being able to return an installation image (and related configuration) back to the state prior to the failed upgrade. The exact mechanism employed here could vary from simply applying (and then removing) individual updates, in the appropriate dependency order, or employing some kind of transaction processing model, allowing entire upgrades to be performed before commit (and therefore not committing when a failure occurs).	P?	No, but side-by-side install will help support such an approach
ADM-10	Inventory Installations
ADM-10.1	Easily determine installations available to an OS instance	Consult OS-specific installation or management tool to list installed images. For example, integration with Windows Add/Remove Programs. Perhaps visibility within a Linux or Unix package database for each installed image.	P1	Depends on OS platform and desktop. Yes, for Windows in that Add, Remove Programs will be supported. Note that support depends on install framework in use. See ADM-12.1.
ADM-10.2	Determine health of distribution		P1	Need clarification on the requirement. Does it intend to require the ability to determine the health or integrity of the packages installed in an image? If so, then we need to check with IPS project to see if this feature is being delivered in IPS.
ADM-10.3	Locate package(s) which contains specific component(s) or file(s)		P1	Yes, shared requirements with OpenSolaris
ADM-10.4	Find installed images via desktop applications menu		P1	Yes, at least for Windows and Gnome desktops. Mac OS may not have a conventional method in this case.
ADM-11	Direct Package Level Operations
ADM-11.1	Manually obtain and transfer discrete packages	Redundant with earlier requirement?	P1	TBD. Need to confirm with IPS project that users will be able to manually obtain discrete packages.
ADM-11.1	Manually install discrete packages	Given a package residing on an accessible filesystem, the ability to use both a GUI and a CLI to install the package.	P1	Yes, shared requirement with OpenSolaris
ADM-11.2	Manually update discrete packages	Same as previous, but the ability to update an installed package.	P1	Yes, shared requirement with OpenSolaris
ADM-11.3	Manually remove discrete packages and be notified of dependencies prior to removal	Ability to use both a GUI and a CLI to remove a package.	P1	Yes, shared requirement with OpenSolaris
ADM-11.4	List content and metadata of a package including install location and change log	Both for installed and not yet installed packages. Via both a GUI and a CLI.	P1	Yes for content, metadata and install location. TBD on change log. Need to determine if IPS will support delivery of change log information.
ADM-11.5	Verify correctness/integrity of a package	Both for installed and not yet installed packages. . Via both a GUI and a CLI.	P1	Yes, shared requirement with OpenSolaris. Need to confirm degree of support planned by OpenSolaris.
ADM-11.6	Depend on CLI package level interfaces over a long period of time.	Support these interfaces for periods that are consistent with the support life of commercial software products. For example, 5+ years. Long-term compatibility of GUI tooling is less important across major releases of products.	P1	Yes, worst case, since we ship a copy of IPS on non-OpenSolars platforms, we could freeze our version. On OpenSolaris, where unbundled distros would depend on the OpenSolaris IPS pkg CLI, we need to carefully manage expectations since that interface could change as OpenSolaris changes.
ADM-11.7	New versions of package level CLI's must support prior versions of the packaging interface/format/infrastructure and registry.	Users expect to interact with a fairly stable package CLI over the life of the product (but probably could deal with some amount of compatible change). It is important as users install newer versions of our packaging tools that those tools continue to behave correctly against prior versions of the packaging interface/format/infrastructure and registry that may already exist on a target system. Requiring users to use specific versions of the package CLI against specific versions of packages would lead to a fairly poor user experience.	P1	See previous item's response.
ADM-11.8	Down-rev package level CLI's should work with packages created against up-rev versions of the packaging infrastructure.	As the packaging interface/format/infrastructure evolve to handle new features it would be ideal if down-rev package tools can continue to interact with the packages based on the newer interfaces albeit without the capability of using new features offered through the newer packaging interfaces.	P2	See previous item's response.
ADM-12	Remove Installations
ADM-12.1	Carry out removal or update of an installed image from within the installed image	For example, an "uninstall" executable should be easily found near the top of each installed image.	P1	Yes, as a fallback where Add/Remove programs and/or Start/Applications menu integration is not feasible, it seems reasonable to place an uninstall executable in the root of each install image. Implementation of this feature may depend on the install application framework in use.
ADM-12.2	Trigger removal or update of installed image using OS-specific installation tool	For example, click on installation image's Add/Remove Programs entry to launch a tool to be able to remove or update an installation image	P1	Yes, on desktops where readily feasible such as Windows Add/Remove Programs area. Perhaps not as feasible to implement for other OS platforms - especially when non-root user is installing products.
ADM-12.3	Trigger removal or update of an installation image through desktop applications icon		P1	Yes, each installed image should result in a Start or Applications menu item that allows for easy uninstallation of the entire image. Unclear as to the extent of support provided on Mac OS and other non-Windows and non-Gnome desktops.
ADM-13	Take Advantage of OS-Specific Features
ADM-13.1	Solaris: Zones Integration	Meeting this requirement should become very straightforward with the implementation of multi-install support.	P1	Yes, multiple UC-based install images will be exercised within the same non-global zone and the same product installs will take place in the global zone and non-global zone to demonstrate isolation.

Integrator Use Cases

#	Title	Description	Priority	Response
INT-1	Embed an installation
INT-1.1	Ability to embed an installation image and associated configuration into another product	Obviously needs drill down and some insight from OEM experts.	P1	Yes, in the sense that multi-install will help facilitate embedding of products into OEM products. However, the UC 2.x project won't be providing an end-to-end solution. ISV Engineering might be able to help build out this solution by validating that embedding an UC 2.x-enabled distro within a 3rd party product is feasible.
INT-2	Update API
INT-2.1	Formal API to underlying update capabilities.	So that 3rd parties can implement update clients	P2	See API response above.

Update Rollback Scenarios

There are several possible levels of update rollback implementation which could be used in UC 2.0 to satisfy requirements. Refer to this writeup for more details.

Comments/Issues

This section is used to store comments that have been made on the requirements before they are factored into the rest of the document.

From Eduardo:

• UC2 & multiple repositories - We need to have multiple repositories, with different SLA, and represent that in the UI. For example, a community repository, a Sun-supported repository, etc.
• UC started from GlassFish - Avoid having to fire UC manually. GF admin console should just say: "There are updates, click 'here' to fire UC"
• UC pings carry ServiceTag information
• Web browseable repository (this is more of an IPS requirement)

History

Date	Change	Notes
April 24, 2008	Changed Windows 2000 to 2003 Server

This page (revision-45) was last changed on 29-Apr-08 12:05 PM, -0700 by TomMueller.
This page was created on 11-Sep-07 11:37 AM, -0700 by 192.18.122.63.

More info...