IAM ====== 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): garrett-0 What is the goal for S10C zones? Response: To provide an S10 compability environment for applications that customers don't want to port to S-Next. This is not an attempt to emulate a full standalone system. 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. Response: The project team will investigate this and add this to the list of things to cover. 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. Response: Project teams backporting to Sol10 need to be aware of this feature. The ARC feels that management needs to understand the resource impact across the organization and recomments contracts be obtains for all Private interfaces for the user/kernel boundary. seb-01 Implicit VLAN creation was removed by the Crossbow project, and is something that is supported under s10. This is the ability to plumb an IP interface with a special PPA, and the DL_ATTACH_REQ message sent down to the DLPI link to attach to that special PPA causes the driver to automatically create a VLAN link. How will this be handled? seb-02 The architecture surrounding IP tunnel administration was totally reworked by PSARC 2009/373, and I know the project has thought about ways to handle this (I was involved with those discussions). Will the ultimate solution to this problem (assuming that you figure out how exclusive stacks will work) be documented in the case materials? It would be generally useful to have documentation of how particularly "hairy" areas such as this are being handled. Response: For seb-01 and seb-02 this applies to phase 2 of the project which will support exclusive stacks. THE NEXT STEP ============= Return for commitment