2N/A Each collection of installed package instances is some kind of
2N/A image. We envision three kinds:
2N/A An entire image contains (and can contain) all appropriate
2N/A packages from a repository. It has a machine type and release.
2N/A A partial image contains (and can contain) all appropriate
2N/A packages from a repository. An partial image is tied to an
2N/A entire image and has an identified list of non-writeable
2N/A directory paths. It inherits its machine type and release.
23N/A A user image consists entirely of relocatable packages. It is
23N/A tied to an entire image for dependency satisfaction of
23N/A non-relocatable packages. It inherits its machine type and
32N/A2.2. Image configuration
32N/A2.2.1. Configuration inheritance
32N/A Some aspects of configuration can be shared between all images. For
32N/A instance, a user image may specify publishers beyond those encoded
58N/A into the system defaults. So, a user image must have authoritative
32N/A configuration, but be able to draw on the parent image's state for
225N/A Operations on partial images and non-live entire images may need to
225N/A access image configuration data when smf(5) for that image is
225N/A unavailable. So images of these kinds must have cached
225N/A Roughly, these aspects are sufficient to constrain our configuration
225N/A behaviour for user and entire images:
38N/A look up local configuration
38N/A if unavailable, examine parent's configuration cache
38N/A if undefined or unavailable, use hard-coded default
83N/A if unavailable, examine configuration cache
83N/A if undefined or unavailable, use hard-coded default
2N/A Partial images could have differing behaviour depending on whether
92N/A the operation is invoked from within the partial image's "packaging
92N/A context" (as it would be for an operation issued from within the
92N/A zone), or outside it (operations on the entire image and its
2N/A associated partial images).
313N/A For the first case, the configuration strategy is the same as that
2N/A for an entire image. For the second case, we could do
2N/A [partial image, external context]
313N/A examine partial image configuration cache
313N/A if undefined or unavailable, examine entire image configuration
2N/A if undefined, use hard-coded default
53N/A For certain properties (or even certain packages), it may be
34N/A inappropriate to let the partial image configurations drift from
70N/A that of the entire image.
2N/A2.2.2. Configuration components
2N/A List of publishers. For each publisher, we have a prefix, an
70N/A origin URL, a list of mirror URLs, and annotations.
2N/A /prefix pkg: publisher
70N/A /origin http:, https:, or ftp: URL
70N/A /mirrors list of URLs
70N/A /disabled boolean indicating whether publisher should be used
70N/A Image properties. The image has a collection of simple properties,
70N/A like machine type and policies that control the behavior of the pkg(5)
70N/A software within that image. Policies are properties with a boolean value.
70N/A /pursue-latest (not currently used)
6N/A /require-optional (not currently used)
6N/A /display-copyrights (not currently used)
6N/A /flush-content-cache-on-success
34N/A should downloaded compressed files be removed
34N/A after a successful install
34N/A /preferred-publisher preferred publisher for unknown package lookups
34N/A /title title of image for use in GUIs and other UIs
34N/A /description longer description of the content of the image
313N/A Entire images have a property group for each tied partial image.
38N/A /path Filesystem path
34N/A /vdomainname Defined if this image is a virtual
92N/A domain controlled on this system.
145N/A /vdomaintype "xen", "zone", ...
92N/A (XXX Should we instead assume that each of Zones and Xen will
92N/A2.3 Image-filesystem interactions
92N/A The intent is to utilize snapshot-capable filesystems to provide a
313N/A rollback mechanism that includes both the pkg(1M)-driven
38N/A modifications as well as subsequent modifications from configuration
34N/A methods, etc. In most cases, we are considering a filesystem with
38N/A capabilities similar to ZFS.
2N/A XXX Is fssnap_ufs(1M) sufficient to build something meaningful for
With appropriate policies set, the image plan, prior to execution
must snapshot the involved filesystems.
There seem to be two options:
1. The image can build its list of filesystems and types (plus
other attributes, like mutability.
2. A list of filesystems is given to each package plan, the package
plan then evaluates its proposed actions against that list, and
offers a method to return the affected subset of the list.
In this case, we must also determine whether or not we are
restricted to clones (because one or more packages in the image
plan require kernel-restart) or are potentially live.
model, where the substrate owns the low-level properties specific to
a particular "place to write data".
In the case that one or more filesystems in the image is or are not
capable of snapshots, we have two choices:
- take no snapshot, as image-revert not possible in any safe or
- take a set of snapshots that lead to a revert point that requires
We must warn about images of this kind, unless policy settings allow
us otherwise. Since we want to allow and understand "zfs
split"-style operations [1], we also need to determine if a snapshot
set taken before a split can sensibly be restored after the split