OpenSolaris

Upgrading Containers (Zones) with Snap

As part of the Snap project, Containers (Zones) must be able to be Snapped (upgraded). Currently Containers are upgraded via the Standard and Live Upgrade programs. Pfinstall and libspmi*.so.1 libraries were modified to natively support upgrading Zones by determining which packages were needed for each Container, including the Global Container, and then removing/adding packages based on their installed content. For Snap, the snap engine will defer the logic of determining how the Containers are upgraded to the new packaging system. 

Snap will be responsible for Container metadata management, File System propagation of the Containers to be upgraded and interfacing with IPS.

Proposed Requirements

Snap requirements on the new packaging system (IPS):

The new packaging system will...

• Natively be able to upgrade a whole or sparse root Container which is physically represented on a ZFS file system.

• Allow divergent Container data and will be able to upgrade Containers one at a time or in parallel. Containers do not have to be upgraded as an "all or none" transaction as is currently the method for installing to a Container.

• Allow multiple Containers (including the Global Zone) to be passed as a whole representation of the Solaris instance being Snapped and will be able to upgrade all Containers contained within the Solaris Instance being upgraded.

• Be able to determine if their is enough space available for the Container's to be upgraded.

• Must have the minimum ability to copy the data off of the non-ZFS File System to a ZFS Files System and then upgrade that newly created Container.

Snap requirements:

Snap will...

• Remove the dependency on pfinstall for upgrading Containers.

• Be able to upgrade a non-ZFS Container (UFS) to a ZFS dataset within an existing ZFS pool. This also includes Containers on other Files Systems like VxFS or QFS.

• Be able to recognize that a Container contains a separate non-shareable File System. e.g. A separate /var used exclusively for the non-global Container. The contents of this File System will be copied to a separate ZFS dataset on the ABE and will be used exclusively for that non-global Container.

• Provide an interface so that a user can manipulate individual Containers contained in an Alternate Boot Environment. The interface will allow copy, delete, or update operations on the ABE.

• Provide arguments to the packaging system so it can upgrade to the users specification. Those arguments could be specified as either:
• A global representation (Solaris Instance) of all the Containers or
• One Container at a time.

• Rollback to the last known good snapshot if a Container fails to upgrade.

• Be able to upgrade a Container without knowledge of other Containers. This means that an upgrade will continue if a subset of Containers failed to be upgraded successfully. 

• Be able to upgrade all or a subset of Containers in parallel.

• Be able to upgrade the Global Container separate from the non-global Containers. Non-global containers will be detached when upgrading the global Container on the ABE and attached after the ABE becomes active.

• Be able to upgrade multiple Containers in multiple zfs pools.

• Not upgrade non-native zones. Non-native zones will be considered shared and left alone no matter which FIle System they live on.

• Maintain a log that will be informative enough for an admin to attempt to fix a Container if it failed to upgrade.