*Attendees*
Ginnie, Sue, Mary, Sanjay, Barbara, Karen, Dave, Jan, Alok, Jack, Jean,
William, Sundar, Joe, Tycho, Greg, Evan
*Notes*
> 1) Welcome
> - Purpose of the Install support for SPARC project
- Provide a working sun4v OpenSolaris distribution,
based on IPS SPARC packages, in January development build
- Build and install the SPARC distribution using the tools
we've developed. (Adapt the tools to SPARC)
- Combined effort of people on DC, AI and Snap projects, plus...
> - The team welcomes Greg & Tycho
- They are our SPARC consultants.
- For now they will be looking into building SPARC image
based on latest Nevada without a repo.
- Look into SPARC-specific changes needed to ICT module
- Look into Target Instantiation to create a disk label
if disk doesn't have one.
>
> 2) Logistics
> - open project meeting: Weds 9:30am PT / 10:30am MT/ 12:30pm ET/
5:30pm
PRG
- (latter half of Caiman program meeting time slot, plus 1/2 hr)
- Purpose of the meeting is to handle roadblocks, coordinate between
teams, share info. Essentially, DC, AI and Snap are doing the same
thing in three different contexts: booting and using SPARC.
>
> 3) Assumptions
> - sun4v support only (no sun4u)
- current planning & scoping is done for sun4v only.
If/When this changes, the schedule will change accordingly.
> - 2G internal memory needed for the large SPARC image
- For AI, this is RAM needed on the target machine to install.
- Not worth worrying about as most sun4v machines have at least
that much memory. Just document
- No GUI auto-installer
- DC produces non-GUI image for AI
- Scope for January is AI only.
- Snap should expect to update what AI installs.
> - SPARC systems for build, development & testing
Development systems:
- Here in MPK we have 4 sun4v systems:
line1-t1000
line2-t1000
line1-t2000
line1-t5120
New system will be delivered to Santa Clara 11/24
Ginnie has a BRM sun4v reserved thru January.
- These can be partitioned into several virtual machines using ldoms.
- This should provide enough virtual machines, assuming enough memory
is available on these machines.
- Ginnie and I are looking into this.
(Post-meeting note: The t1000 machines have 8 Gb each.
Can't ssh into other machines to check them at this time.)
Build machines:
- We have at least two machines at our disposal:
buxton in BRM
osol-bldsp in MPK: V215, 1 GB memory.
- We'll use osol-bldsp as primary build machine as in MPK (so has some
support) and this frees up the additional sun4v machine in Santa Clara
as a development machine, for now.
- I get with Mary tomorrow about adding memory.
- Mary to check with lab support.
- Back up build machine would be in BRM: Buxton.
- We're grateful that Ginnie will be managing the build machine and will be
doing our builds.
If it turns out that with ldoms we have enough working virtual machines
for development, then we may use the Santa Clara sun4v as a build machine
as lab coverage is probably better there.
But for now we'll use osol-bldsp in MPK.
> Dependencies: SPARC repo
> Risks:
> - SPARC repo un-availability causes day to day slip to the
Install end date
> Mitigation:
> - what is plan B ?
Per Dave: Either the repo gets done or we're stuck. Waste of effort to
pursue this without a repo.
>
>
> 4) Testing:
> - what is the test requirement for SPARC support ?
Same tests for X86 should complete for SPARC. Some test implementations
may change slightly for different architectures.
Snap: Jason in China porting testing to sparc. Testing will take 2 weeks
AI: Server is architecture-neutral; no changes required for SPARC.
Same test should work for SPARC. If test team runs short of time,
skip testing of server as an X86 server can serve up SPARC bits
and can install a SPARC system.
DC: Testing should be platform neutral.
> - what new tests need to be developed/executed
AI: Need to accommodate that tests may give different results on sparc
than x86, due to different mechanisms employed for booting and setup.
(difft use of menu.lst, dhcp for example)
> - Who will be in charge of testing?
Same test resources as for X86. So, same teams.
>
> 5) Documentation:
> - what is the requirement for SPARC support ?
Barb not doing formal docs specific to sparc. Instead, set
up wiki of what is available for sparc, and diffs of
sparc vs x86, release notes.
Barb would serve as facilitator of wiki. Engr would update the wiki.
Not a release. Keep this in mind. No press release. Development build
only. Formal documentation not required.
>
> 6) Engineering
> - Revisit list of tasks that require SPARC repo & associated effort
How much can be done with a pkg-image area populated using other means?
Snap: needs repo for testing but can do other development in the
meantime. Can go thru mid Dec without repo. Need repo for pkg
image update and zones.
DC: needs the repo.
AI: installadm tools to set up sparc client, changes to client side: ai
engine. Can do without repo.
Need repo for testing, ict changes, ai engine. Need 3-4 weeks time after
image.
Repo needed 5 weeks before the end of the project:
- 1 week for DC to generate an image.
- 4 weeks for AI to use image for testing.
> - Open issues at present:
> - Use of DHCP
AI: Can DHCP be used to transfer additional info pertaining to the install,
or some other mechanism?
Use DHCP to unify x86 and SPARC setup. Looking into how to do this.
> - What to do on SPARC instead of fdisk
AI: On SPARC, disk partitions as such don't exist so fdisk doesn't exist for
SPARC. Just make slices in the vtoc. On SPARC, the whole disk is the
"partition".
> - Is there any requirement on the currently large image size?
Already covered. Not to worry about small image size.
Questions:
Sanjay: Asked Greg and Tycho if there are any other issues regarding the
latest Nevada bits which could get in they way. Neither Greg nor Tycho
were aware of anything.
