SYSTEM ARCHITECTURE COUNCIL
Platform Software ARC
---------------------------------
PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507.
08-12-2009 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):
Garrett D'Amore: Yes
Tim Marsland: no
ATTENDEES - Members: (6 active members)
Kais Belgaied: Out
Mark Carlson: Yes
Richard Matthews: Out
Darren Moffat: Yes (on sabbatical)
Sebastien Roy: Yes
Glenn Skinner: Yes
Bill Sommerfeld: no (on sabbatical)
Gary Winiger: no (on sabbatical)
STAFF -
Asa Romberger (PM): Yes
ATTENDEES - Interns:
Frank Che no
James Falkner: no (on sabbatical)
Daniel Hain: Yes
Michael Haines: no
Alan Hargreaves: Yes
Phil Harman: no
Wyllys Ingersoll: no
Darren Reed: no
Dean Roehrich Yes
Ienup Sung: no
Phi Tran Yes
Brian Utterback: no
James Walker Yes
Mark Martin Yes (external)
Don Cragun no (external)
Guests:
Tim Haley Yes
Neil Perrin Yes
Jerry Jelinek Yes
Cathy Zhou Yes
Nicolas Droux Yes
-- 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
---------------------------------------------------------------------------
Case Anchors: <br>
<A HREF="#case1">S10C (2009/253)</A> <br>
<A HREF="#case2">VRRP Update (2009/388)</A> <br>
===========================================================================
Fast Tracks:
============
Case (Timeout) Exposure Title
2009/330 (08/18/09) open Fast Crash Dump
let it run
2009/417 (08/05/09) open Deliver libgs.so shared library and
Ghostscript header files
approved
2009/422 (08/12/09) open VirtualBox USB Device Capture
approved
2009/423 (08/14/09) open ZFS logbias property
approved
2009/424 (08/14/09) open idzebra
let it run
2009/429 (08/12/09) open sys/stdbool.h
approved
2009/430 (08/19/09) open Default system CA (X.509) Certificates
approved
2009/427 (08/17/09) closed zone/ops center contract
approved
Next Meeting:
=============
08/19/2009
10:00-10:10 Open ARC Business (use open dial in above)
10:10-10:55 Open Inception: Anti-spoofing Link Protection
(2009/436) Submitter: Eric Cheng
Owner: Kais Belgaied
Exposure: open
===========================================================================
Name: S10C
Submitter: Gerald Jelinek
Owner: Rick Matthews
Intern: Dean Roehrich
Exposure: open
SUMMARY
=======
Use the BrandZ infrastructure to deliver a Solaris 10 (S10)
brand for
Solaris.next (S.next). This will be provided as an adoption and
compatibility aid to enable customers currently running S10 to
easily
adopt S.next while also continuing to run their S10 software within
branded zones. This allows the customer to rapidly switch over to
S.next, creating a win-win situation for Sun and its customers.
For customers:
- Solution to cope with compatibility differences between
Solaris 10 and S.next
- Protect investment in Solaris 10 (infrastructure,
training,
support)
- Leverage new technology in S.next (e.g., crossbow) while
limiting risk to production environment
- Limit total cost of ownership
- Avoid or delay required application recertification
For Sun:
- S.next is adopted sooner
- Provide a compatibility environment for S.next
- Customers will see Sun as a solution provider who is
easing
the burden of getting to S.next
- Minimize the cost of consolidating Solaris 10 systems
- Built-in Solaris feature to aid customer adoption
- Provide cross-platform virtualization solution for
S.next across all hardware (it is the only M-Series
virtualization solution)
As with the existing solaris8 [PSARC/2007/350] and solaris9
[PSARC/2008/125] brands, this project will provide a 'physical to
virtual' (p2v) capability that can migrate an existing S10 software
stack on a physical system into a solaris10-branded zone
running on a
S.next system. In addition, the project will provide a 'virtual
to virtual' (v2v) capability that can migrate existing native
S10-based
zones into solaris10-branded zones running on a S.next system.
This project is planned to deliver as a bundled feature of S.next.
ISSUES
======
PSARC 2009/253: S10C
Submitter: Gerald Jelinek
Owner: Rick Matthews
Intern: Dean Roehrich
Issues for inception (05/27/2009):
ged-1 As of build 115, SXCE/OpenSolaris/Nevada contain a new audio
framework. (PSARC 2008/318 Boomer) This framework has some
potentially incompatible changes which will break certain
applications -- particularly the desktop volume control
applications.
In Boomer we decided that this compatibility was not needed,
since the desktop apps were being upgraded to the Boomer interfaces
at the same time. Is the compatibility here an issue for S10C?
If so, how will it be addressed.
jdc-1 What happens with lofs mounts in v2v? Many people are using
these to work around limitations in Zones -- for example,
adding a writable /usr/local to an otherwise sparse root
zone, adding a "global zone name" file, or sharing data
between zones.
jdc-2 What sorts of factors should the ARC consider when granting
patch/micro release binding? Are there specific areas where
updates to the branding module will be needed?
(One caution here is that some private interfaces, even those
that cross the kernel/user barrier, are changed occasionally
without ARC review. Merely requiring the ARC to note this
issue may not be sufficent to be 'safe'; restricting change
will also be necessary.)
(In the past, we've been saved by circumstance: there are very
few backports to S9 or older, so even though "patch/micro"
authorizes them, they don't happen, and haven't been
considered in the past. Without an enterprise OpenSolaris,
S10 is currently different.)
jdc-3 Meem's comments about the non-Crossbow projects (such as
Clearview) that affect whole root zones will also need to be
addressed in the commitment.
gw-1 What is the list of S10ux "Features" that are not supported?
You note zones and TX, and exclusive stacks. Are there others?
ram-1 Are you providing a 20Q? (Team previously responded that
one would be provided by commitment).
ram-2 Regarding versioning, would any S.next release be allowed
to discontinue functionality provided by S10U8 brand? If so,
what would EOL rules look like.
ram-3 Is this project processor architecture independent? (Previous cases
cited market restrictions).
Unresolved additional questions asked during the inception review
(05/27/2009):
ged-2 Concerned about guidance to cteams about handling
order of integration to sol10 or ON, when a feature requires an
update to the version in the brand module.
Several:
Must provide guidance to cteams and to project teams so they know
when they are doing something that requires modification of the
brand module.
Issues for 2nd inception (08/12/2009):
djm-1 Unlike the solaris8 and solaris9 brands applications running in
a solaris10 brand will be explicitly privilege aware. This should
be fine in most cases. However there are two changes that
could impact a solaris10 brand with respect to privileges:
PSARC/2009/378 Basic File Privileges
PSARC/2009/377 In-kernel pfexec implementation.
Should a solaris10 brand "see" the new expanded basic privs ?
Apps should be well written because it has always been documented
that "basic" can expand but we haven't done it yet. Also should
"basic" expand in the solaris10 zone when it does in the running
kernel.
There shouldn't be any impact from 2009/377 and I don't expect
that a solaris10 zone would use this model but I think it should
investigated for any possible issues.
djm-2 Crypto Framework Impact
pkcs11_kernel (not libpkcs11) and /dev/crypto are intimately
tided together. This case appears to put a very strong constraint
on the crypto team to only ever make compatibe changes to our
private /dev/crypto interface, I'm really not happy about that
it has effectively elevated a Project Private interface to
Committed Private.
This should be relatively easy to verify by running the
STC2 security/ef test suite in a solaris10 brand when using an
UltraSPARC T2 machine.
Similarly for cryptoadm(1M) and /dev/cryptoadm.
While there is a private interface between kcfd and misc/kcf
that is only used in the global zone so it isn't an issue for
a branded s10 zone.
THE NEXT STEP
=============
Return for commitment
===========================================================================
Name: VRRP Update
Submitter: Cathy Zhou
Owner: Sebastien Roy
Exposure: open
SUMMARY
=======
This case describes several design issues of the existing VRRP case
(PSARC/2008/693 VRRP) and the proposals to address those issues.
ISSUES
======
THE NEXT STEP
=============
Approved (Sebastien Roy, Kais Belgaied, Garrett D'Amore)
