.de Sc
\\s-1\\$1\\s0\\$2
..
.ds cA 2005/474
.ds aR \s-1PSARC\s0
.LP
.so ../../amac
.Co
.ds LF \fI\*(aR/\*(cA\fP
.ds RF \fICopyright 2005 Sun Microsystems, Inc.\fP
.if n .ds CF
.IP \fBSubject:\fP 15
Zones Upgrade (Ashanti and Zulu)
.IP "\fBSubmitted by:\fP" 15
James Carlson
.IP \fBFile:\fP 15
\*(aR/\*(cA/opinion.ms
.IP \fBDate:\fP 15
September 21st, 2005
.IP "\fBCommittee:\fP" 15
James D. Carlson,
Ed Gould,
Gary Winiger,
Shudong Zhou.
.IP "\fBProduct Approval Committee:\fP" 15

Solaris PAC
.br
solaris-pac@sun.com

.pn 2
.NH
Summary
.LP
The Zones Upgrade project provides a phased approach towards full
support of upgrading Solaris systems with non-global zones.  In the
first phase, called "Ashanti," patches will be used to deliver the
bits that would ordinarily be delivered by packages in a standard
upgrade.  The second phase, "Zulu," will deliver Live Upgrade and
freshbitted package upgrade support.  Only Ashanti is fully described
by this case.
.NH
Decision & Precedence Information
.LP
The project is approved as specified in references [1] through [6].
.LP
The project may be delivered in a patch/micro release of Solaris.
.NH
Interfaces
.LP
The project exports the following interfaces.
.if n .ne 8
.if t .ne 3
.TS H
box;
c s s
l | l | l.
Interfaces Exported
_
Interface	Classification	Comments
_
.TH
nfs_global_client_only	T{
Contracted Project Private
T}	See [1], [5]
zlogin -R	T{
Contracted Project Private
T}	See [1], [6]
zoneadm -R {un,}mount	T{
Contracted Project Private
T}	See [1], [6]
{pkg,patch}{add,rm}	Project Private	See [1], [2]
scratch zone support	Project Private	See [1]
libzonecfg	T{
Contracted Project Private
T}	See [1], [6]
Jumpstart keywords	Unstable	See [3]
patch script rules	Sun Private	See [4]
.TE
.NH
Opinion
.LP
In general, the ARC members understood that what was being approved in
this case represented a time-pressured recovery plan for a bad
situation.  Thus, although there were clearly unresolved issues that
stood out as longer term problems to be addressed, the committee
agreed that this project represents one step on that road.

.NH 2
Case Boundary
.LP
Several members felt that the case materials left the boundary for
this case, and therefore what was being approved by the committee,
unclear.  The case describes the details of Ashanti (references [1]
and [2]) and provides an outline of Zulu (reference [7]), but does not
contain the full details of the latter.

The project team responded that approval of this case would set the
contents of Ashanti, and that the plan is to bring future cases to
describe the detailed contents of Zulu.  The reason for providing some
of the Zulu overview in this case is to allow for a discussion of the
roadmap, as best it is known now, and to set the expectation for
future cases to come.

.NH 2
NFS And Zones
.LP
The effect of "Clarification of Cross-Zone Descriptor Restrictions"
(PSARC 2004/357) has come home to roost.  That other project
effectively outlaws all cross-zone uses of NFS mount points.

The miniroot itself (on SPARC systems) is mounted over NFS, which
means that all of the binaries (including zlogin) are accessed via
NFS, and thus cannot invoke zone_enter.  In addition, the patch tools
assume direct access to the patch and have no mechanism for dealing
with file descriptor non-transportability into zones as described in
2004/357.

The result is a serious problem for this project, and an /etc/system
hack that gets around it in the short term.  This issue led to the
advice to the PAC, listed in section 6 below.

.NH 2
The Long Run
.LP
The long term implications were discussed at some length.  The project
team indicated that there are many steps on this road, and that
there's a project running now that will make this story clearer.
However, some rough details are known now for the Solaris 10 Update
series.

In Update 1, only Standard Upgrade would be supported on all systems,
including those that have non-global zones installed.  Live Upgrade
would work only for systems without non-global zones.  This project
provides that solution.

In Update 2, both Standard and Live Upgrade will work, although it is
likely that Standard Upgrade will still use the Ashanti (patch-based)
mechanism.  A future case will describe the LU (Zulu) changes.

In Update 3 or some future update, both forms of upgrade will work,
and the plan is to make Standard Upgrade rely on the same underlying
mechanisms as Live Upgrade.  This will be the end of the Ashanti
solution.  A future case will describe the Standard Upgrade changes
required.

Longer term, the plan is to steer customers towards solutions that
reduce downtime and the pain of patching and upgrades.  This means
looking at Purple Haze, greater reliance on Live Upgrade, and a
simplification of the existing code base.

.NH
Minority Opinion(s)
.LP
None.
.NH
Advisory Information
.LP
The Solaris PAC is advised to fund a project to remove the cross-zone
restrictions from NFS.

.NH
Appendices
.NH 2
Appendix A: Technical Changes Required
.LP
None.
.NH 2
Appendix B: Technical Changes Advised
.LP
None.
.NH 2
Appendix C: Reference Material
.LP
Unless stated otherwise, path names are relative to the case
directory \*(aR/\*(cA and are normative.
.IP 1.
Scratch Zone design document.
.br
File:
inception.materials/scratchzone-design.pdf
.IP 2.
Interim (Ashanti) Update design document.
.br
File:
inception.materials/interimUpdateDesign.txt
.IP 3.
Jumpstart keyword disposition.
.br
File:
inception.materials/jumpstart.txt
.IP 4.
Patch script rules
.br
File:
final.materials/patch-rules.txt
.IP 5.
Contract for NFS temporary cross-zone work-around
.br
File:
final.materials/contract-01.txt
.IP 6.
Contract for Scratch Zone support
.br
File:
final.materials/contract-02.txt
.IP 7.
Zones Upgrade (Zulu) design document.  (Non-normative)
.br
File:
inception.materials/upgradezone-3.3.pdf