Hash: SHA1


What you have proposed makes sense to me.  I vote to go ahead with it.


On Thursday February 12, 2009, Andy Kurth wrote:
> I would like to begin defining and documenting the API for the backend code
> as people are actively working on developing new modules.  I have begun
> some pages on the Confluence site and would like to start discussing this.
> API development is somewhat related to the image capture and modularization
> issues discussed at the meeting on 2/5.  Solving the issues requires the
> modularization architecture to be modified and the API should be
> specified/updated along the way.
> The main problem is that xCAT.pm expects the OS to reboot when the OS
> capture tasks are done and vmware.pm needs the OS to shut down.  xCAT.pm is
> currently the only provisioning module which has had the OS-specific code
> removed and is fully modularized.  vmware.pm still contains OS code.  It
> will be difficult to modularize vmware.pm and the ESX.pm module that Brian
> and Andrew are working on because of this.
> I have given it some thought and would like to propose the numbered changes
> below.  These changes probably sound bigger than they really are.  Minor
> changes would need to be made to xCAT.pm and image.pm.  This will be easier
> to understand if you look at the diagram on the following page:
> http://cwiki.apache.org/confluence/display/VCL/Image+Capture+Sequence
> 1. The name of the OS module's capture_prepare subroutine will be changed
> to pre_capture().  The reason for this is to align the name of the main OS
> capture subroutine with the main OS load subroutine - pre_capture() and
> post_load().
> 2. image.pm will no longer call the OS::pre_capture() subroutine.  It will
> be the provisioning module's responsibility to do this.  This allows the
> provisioning module to have greater control over the capture sequence. 
> image.pm will only call the provisioning module's capture() subroutine. 
> This makes better sense to me because provisioning engines can be quite
> varied and the sequence should really be driven by the provisioning module.
> 3. OS::pre_capture() will accept an optional argument named 'end_state'
> with possible values 'on', 'off', 'reboot'.  This instructs
> OS::pre_capture() what to do after completing its image capture steps. 
> Because pre_capture() will be called by the provisioning module, the
> provisioning module will be able to have the computer left in the state it
> requires.  The default value will be off, meaning the OS will shut the
> computer down after its pre_capture() tasks are done.
> 4. OS::capture_start() will be eliminated.  All OS capture steps will be
> handled by a single subroutine - pre_capture() including the final steps of
> calling sysprep.exe if Windows and leaving the computer in the state
> described in #3.  I don't see a need to separate pre_capture() and
> capture_start().
> 5. Provisioning::capture_monitor() will be eliminated.  Control is passed
> from image.pm to the provisioning module's capture() subroutine.  If
> capture() needs to monitor the image being saved, it can either do so
> directly in capture() or call another subroutine within the provisioning
> module.
> There are some other pages I started on the Confluence site.  They are
> somewhat messy at the moment.  Feel free to add to them:
> General documentation for modularization:
> http://cwiki.apache.org/confluence/display/VCL/Modularized+Architecture
> OS module API specification:
> http://cwiki.apache.org/confluence/display/VCL/Operating+System+Module+Inte
> Provisioning module API specification:
> http://cwiki.apache.org/confluence/display/VCL/Provisioning+Engine+Module+I
> Thanks,
> Andy

- -- 
- -------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University


my GPG/PGP key can be found at pgp.mit.edu
Version: GnuPG v1.4.6 (GNU/Linux)


Reply via email to