Multi-Install Functional Specification

Version 0.2

1.0 Project Description

1.1 Introduction

Multi-Install is the ability to install, manage and operate multiple instances of a software distribution into one instance of the OS at the same time. The instances could be the same version of the software, or different versions. This has historically been an often repeated request of customers, and is a capability that is difficult to achieve with traditional native packaging.

This specification gives a brief summary of the multi-install project. For a much more detailed look at the overall motivation, architecture and strategy for multi-install please see Multiple Installation and Management of Layered Products[1]

1.2 Deliverables

The deliverables for this project are a suite of specifications. These specifications all exist today, and are in varying levels of completeness:

Specification	ARC Case	Status	Description
Multiple Installation and Management of Layered Products[1]	WSARC 2006/130	Pending approval of above	Description of the overall multi-install strategy
Filesystem Layout for Unbundled Software[2]	WSARC 2006/239	Approved	Defines filesystem layout of installation umbrella directories
Dependency Wiring for Unbundled Software[3]	WSARC 2007/445	Under Review	Defines how components within an installation umbrella directories should resolve dependencies on other component
OS Coexistence for Unbundled Software[4]	TBD	In Progress	Defines a set of best practices to handle OS co-existence issues that arise when implementing multi-install (for example handling clashes in the Start menu).

1.3 Relevant UC 2.0 Requirements

The following UC 2.0 Requirements are covered by this document:

2.0 Technical Description

2.1 Architecture

Details of the Multi-Install architecture are given in the specifications listed in section 1.2. The following is a summary of the significant architectural features.

2.1.1 Self-Contain Umbrella Install Locations

Each product distribution is installed into its own umbrella installation directory. This directory is referred to as a user image, or sometimes more specifically as $INSTALL_HOME. A user image is self contained with respect to direct, non-OS, local dependencies. For example all shared component libraries that a product needs are contained in the product's user image.

Each user image may be managed independently. Software may be added, removed or updated in one user image independent of other user images.

The install location is chosen by the user during installation and may be anywhere in the filesystem where the user has write permission.

2.1.3 User Based Install and Management

Multi-install does not require root (or administrative) credentials to install software. Any user can install a software distribution as long as they have permission to write to the installation location.

2.1.4 IPS Packaging and Repository System

Update Center 2.0 has chose IPS (Image Packaging System) for its software packaging system. IPS is an OpenSolaris project and will be the packaging system used for the OpenSolaris Binary Distribution.

IPS supports some key features required to implement multi-install:

• The ability to create independent install images (user images)
• The ability to install software when running without root (or administrative) credentials
• Robust versioning and dependency declaration
• Cross platform support (with help by the UC2.0 team)

2.1.4 Easy, Robust Update

A critical portion of multi-install is to easily and independently manage user images on an ongoing basis, including extending the user image with new software and updating existing software with maintenance updates. This capability is provided by the IPS subsystem, and will be enhanced via a UC2.0 update GUI application.

2.1.2 Consistent Filesystem Layout

The organization of the filesystem within each user image is defined by Filesystem Layout for Unbundled Software[2]. A couple significant points of this layout are:

1. Each component in the distribution may have its own subdirectory within the user image.
2. Read-only data is kept separate from configuration and runtime data.
3. The relative location of components within the umbrella directory are fixed and can be depended upon for dependency resolution.

2.1.4 Robust Dependency Resolution

In addition to specifying local dependencies via the packaging system it is essential to robustly resolve dependencies at runtime. Details concerning this are covered by Dependency Wiring for Unbundled Software[3].

2.1.4 Co-existence

With multiple instances of a distribution installed on the system at the same time there will be namespace clashes in various subsystems of the operating system.

For the filesystem, this is handled by having independent install locations.

For other subsystems, like the Start menu, or smf(5), additional conventions are needed. These are covered by Operating System Co-existance for Unbundled Software[4]

2.2 Interfaces

Interfaces are defined by the specifications and ARC cases given in section 1.2.

3. References

[#1]	Multiple Installation and Management of Layered Products
[#2]	Filesystem Layout for Unbundled Software
[#3]	Dependency Wiring for Unbundled Software
[#4]	Operating System Co-existance for Unbundled Software

This page (revision-5) was last changed on 28-Jan-08 17:07 PM, -0800 by DiPol.
This page was created on 16-Jan-08 15:03 PM, -0800 by DiPol.

More info...