SYSTEM ARCHITECTURE COUNCIL
Platform Software ARC
---------------------------------
PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507.
03-03-2010 MEETING MINUTES
============================================================================
Send CORRECTIONS, additions, deletions to psarc-coord at sun.com.
Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC.
Co-Chair(s):
Sebastien Roy: Yes
Tim Marsland: no
ATTENDEES - Members: (6 active members)
Mark Carlson: Yes
Richard Matthews: no
Darren Moffat: no (on sabbatical)
Garrett D'Amore: Yes
Bill Sommerfeld: no (on sabbatical)
Gary Winiger: Yes (on sabbatical)
Glenn Skinner: Yes (external)
STAFF -
Asa Romberger (PM): Yes
ATTENDEES - Interns:
Frank Che no
James Falkner: no (on sabbatical)
Daniel Hain: Yes
Michael Haines: no
Alan Hargreaves: no
Phil Harman: no
Wyllys Ingersoll: no
Darren Reed: no
Dean Roehrich no
Ienup Sung: no
Phi Tran no
Brian Utterback: no
James Walker Yes
Suhasini Peddada no
Calum Mackay no
Don Cragun Yes (external)
ATTENDEES - LSARC members:
Mark Martin Yes (external)
John Fisher Yes
Guests:
Evan Layton
Venu Iyer
Rich Burridge
Jack Schwartz
Matthias Huetsch
-- GUESTS --
Not all names are captured. Please send email to Asa.Romberger at Sun.com, if
you attended the meeting and your name is missing from the list.
---------------------------------------------------------------------------
MEETING SUMMARY:
================
AGENDA
03/03/2010
10 minutes Open ARC Business (use open dial in above)
45 minutes SNAP BE Management (2010/059)
Name: SNAP BE Management
Submitter: Evan Layton
Owner: Mark Carlson
Intern: Jim Walker
Status: Inception
Exposure: open
---------------------------------------------------------------------------
Case Anchors: <br>
<A HREF="#case1">SNAP BE Management (2010/059)</A> <br>
===========================================================================
Fast Tracks:
============
Fast-tracks:
Case (Timeout) Exposure Title
2009/602 (03/05/10) open Add Text Mode UI and Common Library to
Device
Driver Utility
let it run
2010/069 (03/04/10) open Solaris GUI Install Users Screen
Modification
more time
2010/072 (03/03/10) open RBAC update: user attrs from profiles
approved
2010/074 (03/05/10) open Crossbow resource usage updates
let it run
2010/078 (03/09/10) open xgrep
let it run
2010/080 (03/09/10) open Brussels II addendum
let it run
Next Meeting:
=============
No open meeting
-----------------------------------------------------------------------------------------------
IAM
======
Name: SNAP BE Management
Submitter: Evan Layton
Owner: Mark Carlson
Intern: Jim Walker
Status: inception scheduled 03/03/2010
Exposure: open
SUMMARY
=======
Snap Boot Environment (BE) Management provides the mechanism to
safely update system software by capturing system states and
allowing
previous system states to be re-enabled. It does this by creating
a ZFS clone of the current system.
The definition of a boot environment (also called a BE) is an
instance
of a bootable OpenSolaris environment consisting of a root file
system
and, optionally, other file systems mounted underneath it
(e.g. /usr, /var).
The root file system and all other file systems of the BE which
contain
system software must be zfs datasets.
This project will allow a user to very quickly create a duplicate
image of their running system or other inactive BE, which can
then be
updated and booted.
This project will provide a CLI (beadm) and library (libbe)
interfaces
for consumers to perform the following functions:
- list BE's
- This includes a BE's attributes.
- create/destroy a BE
- mount/unmount a BE
- activate a BE
- This makes the named BE the default BE on the next reboot.
- rename a BE
- rollback a BE
- This rolls the BE's back to the state of a previous
snapshot.
This functionality will be used to do upgrades of the system.
This will be done through the functionality provied by the "pkg
image-update" command from pkg(5). Management of the BEs createdi
will be done through the beadm CLI.
ISSUES
======
seb-1 I would expect this case to officially EOF Live Upgrade. Unless
I'm mistaken, I don't believe that any other case has done this.
(ejl) Since this case does not support Solaris 10 and we are still doing
updates to to Solaris 10, we are not at a point where we can EOF
Live Upgrade.
seb-2 Need to specify if beadm will be part of a rights profile.
(ejl) Yes the package will deliver these entries:
::::::::::::::
etc/security/exec_attr.d/SUNWbeadm
::::::::::::::
Software Installation:suser:cmd:::/sbin/beadm:uid=0;gid=bin
::::::::::::::
etc/security/prof_attr.d/SUNWbeadm
::::::::::::::
Software Installation::::profiles=ZFS File System Management
seb-3 Does beadm adhere to the least-privilege model? Are there any
related authorizations?
(ejl) Only beadm list can be run without "root" privileges.
seb-4 Section 1.3 of SNAP_BE_techdesc.txt: The first sentence isn't
entirely clear to me. Given that native zones only support
pkg(5), and that every other kind of zone is in fact a branded
zone that is not tied to the current BE's OS verion
(i.e. s10c), it would appear that all zones fall under the
"supported" category. Am I missing the intent of that
sentence?
(ejl) Since it was not yet the case that native zone supported pkg(5)
this sentence was written to try to make it clear that only zones
that supported pkg(5) would be supported. At the point that this
was written only the ipkg branded zone was supported. When this
becomes the native zone then this will be supported.
Maybe the first paragraph for section 1.3 should be rewritten to
make this clearer:
Support for zones will be limited to zones that support pkg(5).
Branded zones that do not support pkg(5) or are not tied to the
current BE's OS version, such as Linux branded zones, are not
managed at all and are shared between BEs without any changes.
For Solaris zones, only installed or running zones are copied
into a new BE.
I updated the document.
seb-5 Please include the Snapzoneslayout.pdf document as part of
your materials, or at least absorb the relevant information
into your materials.
(ejl) Added
seb-6 What consolidation will this be delivering into?
(ejl) ON
ram-1 When an alternate BE exists, is it possible to mount it
automatically
at boot time?
(ejl) No. Only the active BE is mounted at boot time.
ged-0 Along the lines of seb-1 where this case seems to replace LU, it
also seems that this case is going to depend on / being zfs. I'm
not sure that a "requirement" for / to be zfs has been approved at
PSARC yet. Perhaps another case is required to do that?
(ejl) Yes. This tool only supports ZFS root. This would be outside the
scope of this case.
ged-1 I know at least one project is working on integration of grub-2.
Have you been working with this team? This could have significant
ramifications for this effort.
(ejl) Yes we are in contact with them on a regular basis and any
implementation changes needed will be made at the point that grub-2
is available.
ged-2 The case materials say findroot is used on x86, but not sparc. Why
not sparc? It seems like this is another area where our sparc/x86
differences could be simplified, but perhaps I'm overlooking some
critical issue?
(ejl) Isn't findroot specific to GRUB and at this point specific to x86?
THE NEXT STEP
=============
Draft opinion
