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

...

• request state is "image"
• image.deleted = 1, this prevents the new image from being available for checkout until the image creation process is done
• reservation contains image information is for the new image, not the image used as the base image

...

• image.pm::process()

...

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

...

• logoff user
• remove user account
• make sure DHCP is enabled on the private NIC
• 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

...

• 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

• 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.

...

...