Received updated man page from tech writer. Updated webrev to include man page. Online copy available at
http://jurassic.sfbay.sun.com/~ae149097/AI/IOSSS/p5.html On Jun 17, 2011, at 3:12 PM, Kristina Tripp wrote: > > Please review http://cr.opensolaris.org/~enpointe/cr_7054528/ > > Code changes for > > 7054528 js2ai is generating <partition> for all architectures > 7054569 jsai update timezone generate to agree with manifest changes > introduced by CR7043012 > 7055561 js2ai not handling partition default properly > 7055710 js2ai update sc_profile translation for hostname > 7056207 mixing pool and usedisk keyword results in slice referencing wrong > root pool name > > The primary change here deals how the manifest file is outputted when a > <disk> structure is handled when a Jumpstart profile is processed. > Previously we always outputted our structure with a <partition> > > <disk> > <disk_name name="c1t0d0" name_type="ctd"/> > <partition action="create" name="1" part_type="191"> > <slice action="create" in_vdev="rpool_vdev" in_zpool="test" > name="0"/> > </partition> > </disk> > > and outputted the manifest file as ${profile_name}.xml > > Since partition is not a valid structure for SPARC. This basic design needed > to be reworked to pay attention to the architecture that the profile > represents. The new profile name form is ${profile_name}.${arch}.xml where > ${arch} is "generic", "x86", or "sparc". A generic profile is a profile > that has no architectural specific elements located within it, where x86 and > sparc are aimed at those architectures. When a Jumpstart profile is > processed the architecture for that profile is initially set to GENERIC. If > a x86 or Sparc keyword is processed the architecture is updated to reflect > that architecture. If the architecture is GENERIC and we process a keyword > operation that requires a disk structure to be created, the architecture for > the profile is set to None. Internally we then process the profile as an x86 > profile. Upon the completion of the profile processing the None architecture > value tells us that we need to fetch and generate 2 manifest files for the > profile via fetch_tree(arch) in conv.py. Since internally the profile is > keep as a x86 profile when the architecture is None, to retrieve a sparc > version, the profile is simply modified to remove the <partition> nodes from > the profile. > > Other changes 7054569 and 55710 are simple to update the xml outputted for > the SC Profile to conform to xml changes that have occurred to since the code > for these routines was first coded. > > Unit test pass > no pep8 errors > > Man Page Changes: > > Changes to the man pages have been forwarded to the technical writer. > Current man page with my changes sent to technical write can be found at > http://cr.opensolaris.org/~enpointe/cr_7054528/js2ai.1m.txt > Differences between the current and this version can be found at > http://cr.opensolaris.org/~enpointe/cr_7054528/js2ai.1m.txt.diff > > Outstanding: > There's still a need to test all the js2ai generated manifests and perform > actual installs using those manifests and sc_profile. Since there is no > longer a test engineer associated with this effort I'm planning on performing > this upon completion of adding NIS and LDAP support to js2ai. I'll need > access to a client/server system in order to do this so if someone has a > system they can loan me for a few days next week, that would be very helpful. > > > Kristina Tripp, Senior Software Engineer > Oracle Revenue Product Engineering > 500 Eldorado Blvd, MS UBRM05-171 > Broomfield, CO, 80021 > Office: 303-272-8655 > Email: [email protected] > > Oracle is committed to developing practices and products that help protect > the environment > Kristina Tripp, Senior Software Engineer Oracle Revenue Product Engineering 500 Eldorado Blvd, MS UBRM05-171 Broomfield, CO, 80021 Office: 303-272-8655 Email: [email protected] Oracle is committed to developing practices and products that help protect the environment
_______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
