You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@vcl.apache.org by jf...@apache.org on 2013/02/07 14:54:00 UTC

svn commit: r1443476 - /vcl/site/trunk/content/confluence_export/image-capture-sequence.mdtext

Author: jfthomps
Date: Thu Feb  7 13:54:00 2013
New Revision: 1443476

URL: http://svn.apache.org/viewvc?rev=1443476&view=rev
Log:
modified formatting

Modified:
    vcl/site/trunk/content/confluence_export/image-capture-sequence.mdtext

Modified: vcl/site/trunk/content/confluence_export/image-capture-sequence.mdtext
URL: http://svn.apache.org/viewvc/vcl/site/trunk/content/confluence_export/image-capture-sequence.mdtext?rev=1443476&r1=1443475&r2=1443476&view=diff
==============================================================================
--- vcl/site/trunk/content/confluence_export/image-capture-sequence.mdtext (original)
+++ vcl/site/trunk/content/confluence_export/image-capture-sequence.mdtext Thu Feb  7 13:54:00 2013
@@ -1,34 +1,33 @@
 Title: Image Capture Sequence
-<a name="ImageCaptureSequence-ModularizationExample"></a>
+
 ## Modularization Example
 
-The following diagram&nbsp;shows how the image capture sequence
-differs&nbsp;if different provisioning modules are used \--&nbsp;xCAT and
-VMWare.&nbsp;
+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&nbsp;xCAT and VMWare capture()
-subroutines&nbsp;are *identical*.&nbsp; The image.pm state module does not
-care which provisioning engine is being used.&nbsp; All it knows is that a
+
+* 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 image.pm::process() was
-called,&nbsp;the object can be accessed via $self->provisioner, and the
+called, the object can be accessed via $self->provisioner, and the
 name of the subroutine to call is capture().
-* The&nbsp;calls made by xCAT and VMWare's capture() subroutine&nbsp;to the
-Windows.pm pre_capture() subroutine are *identical*.&nbsp; All a
+* 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,&nbsp;the object can be accessed via $self->os, and the name of the
+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.&nbsp;&nbsp;They assume the OS module's pre_capture()
+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&nbsp;does not&nbsp;care which
-provisioning engine is being used.&nbsp; The steps it performs are
+* 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.
 
-----
-{gliffy:name=Image Capture Sequence - xCAT|space=VCL|page=Image Capture
-Sequence|align=left|size=L|version=13}
+<img src="image_capture_sequence_xcat.png">
\ No newline at end of file