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