I like these changes also, this falls in line with our overall
modularization goal.
Aaron
--On February 12, 2009 3:48:30 PM -0500 Andy Kurth <andy_ku...@ncsu.edu>
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+In
terface+Specification
Provisioning module API specification:
http://cwiki.apache.org/confluence/display/VCL/Provisioning+Engine+Module
+Interface+Specification
Thanks,
Andy
Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu
