Thanks for the review

Adjusted the comment so it's a bit more clear. 

        """Output the profile for the specified xml tree.  If skip_validation
           is set to False,  validate the xml tree and recorded any errors in
           the conversion report

        """
There aren't any default values in this function
All my comments for functions aren't aligned that way.  I'll work on adjusting that if that's the
standard the team is using.

On 06/22/11 11:01 AM, Darren Kenny wrote:
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="" name="1" part_type="191">
          <slice action="" 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


--


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

Reply via email to