You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by Andy Kurth <an...@ncsu.edu> on 2009/02/12 21:48:30 UTC
Image capture improvements and API development
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+Interface+Specification
Provisioning module API specification:
http://cwiki.apache.org/confluence/display/VCL/Provisioning+Engine+Module+Interface+Specification
Thanks,
Andy
Re: Image capture improvements and API development
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andy,
What you have proposed makes sense to me. I vote to go ahead with it.
Josh
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
>rface+Specification
>
> Provisioning module API specification:
> http://cwiki.apache.org/confluence/display/VCL/Provisioning+Engine+Module+I
>nterface+Specification
>
>
> Thanks,
> Andy
- --
- -------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University
Josh_Thompson@ncsu.edu
919-515-5323
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJlI+TV/LQcNdtPQMRAqg5AJ4gebR0Z9saXj3SDP2Nl17+97cM+ACfeASu
IiCvt3ZqmxkRvytu9VeHim8=
=yWlX
-----END PGP SIGNATURE-----
Re: Image capture improvements and API development
Posted by Andrew Brown <br...@gmail.com>.
I like these proposed changes, and am for them. This neatly solves the issue
of having provisioning modules needing to shutdown or reboot machines at the
appropriate time. Now, xcat can reboot the machine when it's has all the pxe
files in place, while the vmware or esx modules can shut it down to take the
image.
-Andrew
Re: Image capture improvements and API development
Posted by Andy Kurth <an...@ncsu.edu>.
The commits I made on 2/26 extended the state modules with the new flow
described in this thread. Up to this point, nothing has functionally changed
because none of the provisioning or OS modules have been committed which have
been modified to use the new flow.
The image capture flow changes and OS modularization that I'm working on are
very intertwined. Vista.pm was the first attempt at modularization and the next
step is to get the other Windows OS's working in the same fashion. I want to
take steps so the code that's already working isn't affected. Here's how I
intend to do this...
See the diagram at the top of this page:
http://cwiki.apache.org/confluence/display/VCL/Operating%20System%20Module%20Inheritance
The current Windows OS modules are using or inheriting from Windows.pm,
Desktop.pm, and Vista.pm. I don't want to change these at all. I plan to
commit new files named Windows_mod.pm, Version_5.pm, Version_6.pm, XP_mod.pm,
and Vista_mod.pm, as shown on the right side of the diagram. This will allow us
to work on and test the new modules without affecting existing, working code.
Once tested and everyone's comfortable with the modularized code, the old files
can be removed and Windows_mod.pm will be renamed Windows.pm, etc. Much of the
code is not actually new. Several subroutines were copied from Vista.pm because
they work for any Windows OS.
It's possible to use the old code and test new in parallel because of the way
the database was designed to handle modularization. All that needs to be done
is to create a new entry in the OS table (call it XP_mod) and a corresponding
entry in the module table with its module.perlpackage column pointing to
XP_mod.pm. Any images you configure with the image.OSid pointing to the new
XP_mod OS type will receive the new code. All of existing XP images will not be
affected. I have begun to document this on the page noted above.
The file named Version_5.pm and Version_6.pm will replace Desktop.pm and
Server.pm (which doesn't actually exist). After working with the different
Windows versions and seeing where the major differences lie, it makes more sense
to organize the Windows inheritance tree by Windows major version rather than
desktop/server.
I have a good bit of the new layout done and will commit it soon if there are no
objections. Please let me know if you have any questions, ideas, or want to help.
Thanks,
Andy
Andy Kurth wrote:
> Thanks to everyone for the feedback. I'll begin working on the proposed
> changes today.
>
> Thanks,
> Andy
>
> Aaron Peeler wrote:
>> 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
>> <an...@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
>
--
Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University
andy_kurth@ncsu.edu
919.513.4090
Re: Image capture improvements and API development
Posted by Andy Kurth <an...@ncsu.edu>.
Thanks to everyone for the feedback. I'll begin working on the proposed changes
today.
Thanks,
Andy
Aaron Peeler wrote:
> 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 <an...@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
--
Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University
andy_kurth@ncsu.edu
919.513.4090
Re: Image capture improvements and API development
Posted by Aaron Peeler <aa...@ncsu.edu>.
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 <an...@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