Page History

Modularization Example

The following diagram shows how the image capture sequence differs if different provisioning modules are used -- xCAT and VMWare. 

Take note of the following:

• The calls made by image.pm to the xCAT and VMWare capture() subroutines are identical.  The image.pm state module does not care which provisioning engine is being used.  All it knows is that a provisioning engine object has been created before

• Interface subroutines should be very generic
• Modules may or may not implement an interface subroutine.  If an interface subroutine is not implemented, the core modules assume it isn't needed.
• OS modules should be completely ignorant of the provisioning engine being used
• OS modules should never have conditional statements regarding the provisioning engine or provisioning architecture.  For example, an OS module should not need to worry about whether the OS is installed on a bare metal or virtual machine.
•  

...

• it's possible that another process is running

...

• image.deleted = 1, this prevents the new image from being available for checkout until the image creation process is done

...

• the reservation image information is changed to contain the new image and imagerevision IDs, not the IDs of the image and imagerevision used as the base image
• it's possible that another 'inuse' process is still running for the reservation, this process will detect that the request state has changed to 'image' and exit

...

• image.pm::process()

...

• make sure image does not already exist in the image repository

...

• change root password to known value 
• logoff user
• remove user account
• make sure DHCP is enabled on the private NIC
• defragment the hard drive
• disable the pagefile
  • set sshd service startup to auto
  • reboot
  • delete the pagefile
• configure auto admin login to login as root
• copy Sysprep, drivers, and scripts to the computer
• set sshd service startup to manual so that it doesn't immediately start up when the computer the image is loaded on boots up

...

• write the currentimage.txt file on the computer
• update nodetype.tab with the new image name
• create a .tmpl file for the new image
• run 'nodeset <node> image' to instruct xCAT to save an image the next time the computer boots

...

• run sysprep.cmd
  • cleans various files from the hard drive
  • copies VCLprepare.cmd script to group policy logon scripts directory
  • copies VCLcleanup.cmd script to group policy logoff scripts directory
  • executes sysprep.exe with the switch instructing it to reboot the computer

...

• continuously check the size of the new image files to make sure they're growing
• continuously check the nodeset status of the computer, imaging is done when it changes to 'boot'
• create hda.mbr, hda.sfdisk, sda.mbr, sda.sfdisk files

...

• update request state to completed
• provisioner::get_image_size() is called
• database tables are updated for the newly created image
  • image.lastupdate timestamp = current time
  • image.deleted = 0
  • image.size = result from provisioner::get_image_size()
  • image.name = imagerevision.imagename, this updates the image to contain the correct revision number in the name
  • imagerevision.deleted = 0, this causes the image to appear in the list available for checkout
  • imagerevision.datecreated = current time

...

• email message is sent notifying the image creator that the process has completed
• email message is sent to the system administrators
• reload request is inserted into the database - the computer is reloaded with the newly created image

• image.pm::image_creation_failed()
  • email message is sent notifying the image creator that the process has been delayed
  • email message is sent to the system administrators notifying them that the image creation process failed
  • request state is updated to maintenance, this prevents vcld from attempting to process or delete the request until an administrator has investigated the problem
  • computer state is updated to maintenance, this prevents any other processes from altering or reloading the computer

...

• was called, the object can be accessed via $self->provisioner, and the name of the subroutine to call is capture().
• The calls made by xCAT and VMWare's capture() subroutine to the Windows.pm pre_capture() subroutine are identical.  All a provisioning engine module needs to know is that an OS object has been created, the object can be accessed via $self->os, and the name of the subroutine to call is pre_capture().
• Provisioning engine modules do not not need to know any of the operating system details.  They assume the OS module's pre_capture() subroutine will perform all the steps necessary for the particular OS to be captured and that the computer will be shut down (or left in the state specified by the end_state argument) when pre_capture() returns.
• The OS module's pre_capture() subroutine does not care which provisioning engine is being used.  The steps it performs are identical.
• A very similar example could be made using the same provisioning engine module and different OS modules.

...

...

• set sshd service startup to auto
• reboot
• delete the pagefile

...

• copies VCLprepare.cmd script to group policy logon scripts directory
• copies VCLcleanup.cmd script to group policy logoff scripts directory
• executes sysprep.exe with the switch instructing it to shutdown the computer

...