[OpenIndiana-discuss] Idea on mixing OI and SVR4 sparse zones

[Jim Klimov]

Hello David et al,

I had a new idea for your project of using OI as a base for
the distro to sustain/update existing Solaris deployments.

In *our* systems management we have relatively little use
for sparse-root zones, but quite a bit more of full-root
ones, and to save on disk space (and minimize human error)
we pre-create a "golden dummy" zone which remains unused
per se, while its zfs clones are used to initialize the
application zones. I understand that other deployments
may have more use for sparse-root zones.

I believe that fundamental differences between zones of
different packaging would be in their branding and the
scripts which implement this zone-branding (i.e. actions
upon boot/attach/upgrade/etc.) - for example, an SVR4
"native" zone-attachment or even bootup might involve
detection of packages installed in the global zone
(or some other SVR4 template zone) and migration of zone
info into the local zone's /var/sadm/install/contents,
/var/sadm/pkg/* and similar databases.

I wonder: if we add support for SVR4 zones into OI, maybe
with an option to support sparse-root zones in some manner
like read-only lofi-mounts of *some* /usr /lib etc. images,
why not also support an svr4-golden zone type which would
be a golden-image zone for mounting into sparse zones (and
maybe for cloning into full-root zones - though any source
zone can be cloned). This way updates of an svr4-golden
zone would automatically propagate into svr4-sparse zones
which are based on this golden zone instance, just like
it used to take place for native SVR4 global zones.

The differences now would be:
1) Instead of one global zone, there can be several golden
    zones to template for different tasks; it would also be
    more simple to have a "full" installation with GUI in GZ
    and a "minimized" installation in its zones

2) The GZ can be of any type (like IPS or DEB), while SVR4
    packaging can be used to instantiate and bulk-upgrade
    sparse-root zones;

3) Possibly, it might make sense to change an LZ's assigned
    golden zone (where it mounts its binaries from) so as to
    change versions or whole software sets - perhaps this
    could aid in one-by-one migrations into newer software.
    Maybe, even, migrate an SVR4-based zone into an ipkg zone
    with an identical set of software in different packaging.

PS: I think some terminology should be made, because the
way I wrote it above, "GZ" stands for Global Zones as usual,
but could be mistaken for "golden zones". Maybe, define TZ
(template zones) or something like that? ;)

HTH,
//Jim Klimov