Hi Kristina,
Thanks for doing this.
Some small comments that I have:
- In modules/__init__.py:
- Nit: The text of the doc string here might be better formatted as:
"""Output the profile for the specified XML tree.
If skip_validation is not set, then the XML tree will be validated and
any errors will be recorded in the conversion report.
"""
- If there are optional arguments here, it might be worth putting them at
the end of the args list and giving them default values - .e.g
skip_validation=False.
Otherwise, looks good.
Thanks,
Darren.
On 17/06/2011 22:12, Kristina Tripp wrote:
>
> Please review _http://cr.opensolaris.org/~enpointe/cr_7054528/_
>
> Code changes for
>
> 7054528 <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=7054528>
js2ai is generating <partition> for all architectures
> 7054569 <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=7054569>
jsai update timezone generate to agree with manifest changes introduced by
CR7043012 <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=7043012>
> 7055561 <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=7055561>
js2ai not handling partition default properly
> 7055710 <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=7055710>
js2ai update sc_profile translation for hostname
> 7056207 <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=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
> <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=7054569> and 55710
> <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=7055710> 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.
>
>
> <http://www.oracle.com/> <http://www.oracle.com/>
> *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] <mailto:[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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
