Background
- Provisioning module objects are created by State.pm::initialize() when a new state object is created.
- Provisioning module objects are available within state modules and OS modules
- Provisioning module objects are not available within other types of modules for safety.
Explain:
- define what we mean by "provisioning system"
- give examples of provisioning systems
- could be bare metal, virtual, differentiated, undifferentiated, a service, a special piece of hardware, eventually VCL could provision various types of resources
- relationships among mgt nodes, computers, provisioning systems (such as computer is assigned 1 prov system at a time)
- computer.provisioningid
- provisioning table
- future: management node to provisioning mapping
- provisioning module implementation is responsible for knowing which OS interactions are necessary
- image.pm calls provisioner->capture, new.pm calls provisioner->load, it calls OS subs as necessary
Provisioning Module Subroutines
It is highly recommended that all provisioning modules implement the following subroutines. There may be many additional subroutines implemented within a provisioning module. These will not be called by any of the core VCL modules.
...
node_status
- Description
- A provisioning module's node_status routine checks the current status of the node. Through the module this routine is aware of how to figure out if a node is available and loaded with the correct image or needs to be reloaded.
- It returns a hash reference with various information, the most important being the "status"
| Code Block |
|---|
ie for the xcat module:
hashref: reference to hash with keys/values
\{status\} => <"READY","RELOAD">
\{ping\} => <0,1>
\{ssh\} => <0,1>
\{rpower\} => <0,1>
\{nodeset\} => <"boot", "install", "image", ...>
\{nodetype\} => <image name>
\{currentimage\} => <image name>
|
- The status key/value tells the vcl system the node is ready or needs to be reloaded.
capture
- Description
- A provisioning module's capture() subroutine saves the current state of the resource.
- For the provisioning of computers, this means saving an image of the contents of the hard drive. Although current VCL implementations focus on provisioning computers, the capture() subroutine does not necessarily need to save an image of a hard drive. A provisioning module may be developed to save the configuration of a network service or some other type of resource.
- The capture() subroutine is responsible for calling the OS module's pre_capture subroutine. This is not called by the image.pm state module because there may be cases where an OS isn't applicable.
- The capture() subroutine is responsible for waiting for the entire capture process to complete.
- Expected Beginning State
- An administrator has configured the resource and initiated the capture using the VCL website.
- The resource is on and accessible.
- The information contained in the data object describes the image which does not yet exist and will be captured.
- Expected Ending State
- The entire capture process is complete or else an error occurred.
- The capture() subroutine has waited for an image to be captured.
- Called By
- Arguments & Calling Environment
- Should only be called as an object method of a image.pm state object ($self->capture())
- No Arguments
- Return Values
- 1
- Resource was successfully captured.
- image.pm may proceed to update the database tables making the image available to be provisioned.
- 0
- Resource was not successfully captured.
- An administrator needs to investigate the problem.
load
- Description
- A provisioning module's load() subroutine is responsible for provisioning the node.
- This means starting a virtual machine, loading a image to disk, or nothing in the case of the standalone lab machine.
- Expected Beginning State
- Expected Ending State
- Called By
- Arguments & Calling Environment
- Must only be called as an object method of a provisioning object ($provisioner->pre_capture())
- No Arguments
- Return Values
power_off
- Description
- A provisioning module's power_off() subroutine is responsible for powering off or down a node.
- Expected Beginning State
- Expected Ending State
- Called By
- Arguments & Calling Environment
- Must only be called as an object method of a provisioning object ($provisioner->pre_capture())
- No Arguments
- Return Values
power_on
- Description
- A provisioning module's power_on() subroutine is responsible for powering on a node.
- Expected Beginning State
- Expected Ending State
- Called By
...
- Description
- Configures the OS so that it can be captured by a provisioning module.
- Configures the OS so that it will successfully boot after the captured image is reloaded on another resource.
- Adds and configures drivers so that the image will load on other resources.
- Removes files which should not be saved in the image.
- Examples of tasks performed by the pre_capture subroutine:
- Log off users which were created for the imaging reservation and delete the accounts
- Set root and administrator passwords to standard, known values
- Disable and delete page or swap files
- Delete temp files
- Copy scripts and utilities to the computer which are required after the computer boots up but before it has network connectivity
- Copy drivers to the computer
- Run a generalization or sealing utility such as Sysprep.exe
- Expected Beginning State
- Resource is up and accessible
- Administrator has configured the resource
- Administrator may or may not have logged out
- Expected Ending State
- (Default) Resource is shut down and turned off
- Image captured of resource can be loaded and booted on other hardware
- Loaded image will successfully boot up, establish network connectivity, and be accessible by the OS module's post_load() subroutine
- Called By
- Provisioning module's capture() subroutine
- Arguments & Calling Environment
- Must only be called as an object method of an OS object ($osa provisioning object ($provisioner->pre_capture())
- Optional Argument:
- Name: end_state
- Type: hash reference
- Description:
- Instructs pre_capture() to leave the resource in a particular state after the subroutine's tasks are complet instead of shutting down the resource.
- Possible Values:
- on - Leave the resource on. Do not shut it down or reboot it.
- off (Default) - Shut the resource down.
- reboot - Initiate a reboot and return.
- No Arguments
- Return Values
get_current_image
| Anchor |
|---|
| get_current_image |
|---|
| get_current_image |
|---|
|
- Description
- A provisioning module's get_current_image() subroutine is responsible for trying to figure out what image is loaded on the node. By reading currentimage.txt located on the node's in root's user directory. This routine can be copied from another module.
- Expected Beginning State
- The node is expected to be online and accessible.
- Called By
- Arguments & Calling Environment
- Must only be called as an object method of a provisioning object ($provisioner->pre_capture())
- No Arguments
- Return Values
get_image_size
| Anchor |
|---|
| get_image_size |
|---|
| get_image_size |
|---|
|
- Description
- A provisioning module's get_image_size() subroutine is responsible for collected the disk usage of the image within the image library.
- Expected Beginning State
- Expected Ending State
- Called By
- Arguments & Calling Environment
- Must only be called as an object method of a provisioning object ($provisioner->pre_capture())
- No Arguments
- Return Values Return Values
- 1
- All pre_capture tasks completed successfully.
- Resource was either shut down or left in the state specified by the end_state argument.
- Provisioning module can proceed to capture the image.
- 0
- Resource OS could not be completely prepared to be captured.
- Provisioning module should not proceed to capture the image.