Resource blocks act as a type of middleware component between catalog items, the Cloud API (CAPI), and the CMDB.

The following graphic illustrates how resource blocks fit between other components in the system:

Resource blocks in the cloud provisioning and governance environment

Blueprints
Each resource block becomes a building block within a blueprint. The blueprint eventually becomes a catalog item (also called a stack) that a user provisions from the Cloud Catalog.
Cloud API (CAPI)
Each resource block defines allowable operations, such as Provision and Deprovision. These operations call various components within CAPI to carry out the operation that is received from the stack.
The CMDB
Each resource block is based on a CI type from the CMDB. Resource blocks also have a response processor that handles responses from the cloud provider to take some type of action in the CMDB, such as creating or updating a CI.

How resource blocks are connected

Resource blocks are connected to each other in blueprints. For example, in this blueprint, a virtual server resource block is connected to storage. The virtual server and the storage are both connected to an AWS datacenter resource block.

Figure 1. Blueprint server with storage
Blueprint server with storage

For these connections to be successful, each resource block needs to specify a type of interface. This graphic illustrates these interfaces:

Figure 2. Types of interfaces for resource blocks
Resource block interfaces
  • The guest interface connects to the resource that is above it. The guest interface contains the operations (also called operation signatures), which allows users to take action on their resource.
  • The host interface connects to the resource below the resource block in the blueprint. The host interface also contains operation signatures.
  • The bindings connect adjacent resources.
Resource blocks can have as many guest interfaces, host interfaces, and bindings as necessary. Connections can be made in different directions:
  • Vertical connections require the top resource block to have the same host interface as the bottom resource block guest interface.
    Note: In blueprints, this vertical connection is called a containment connection.
  • Horizontal connections bind one resource to another, but both resources have to reside on top of the same resource block.
    Note: In blueprints, this horizontal connection is called an attached-to connection.
The same example blueprint with a virtual server with attached storage on an AWS datacenter, the resource blocks are configured as this graphic illustrates:
Figure 3. Interfaces for resource blocks
Interfaces for resource blocks
Resource block Interfaces and bindings
Virtual server
  • Host interface: Compute
  • Binding: to Storage Volume
AWS Datacenter
  • Guest interface: Compute
  • Guest interface: Storage Server interface
Storage

Host interface: Storage Server interface

The binding between the virtual server and the storage is unidirectional. You configure the binding on the virtual storage resource block only by specifying the storage resource block. You do not need to configure another binding on the storage resource block.

Guest interfaces and operations

Each guest interface provides a default set of operations (also called operation signatures) that allow the user to choose what they want to do with a virtual resource. The most common operation is Provision, which means that a virtual resource is created. Many guest interfaces and corresponding operations are provided by default with the Cloud Provisioning and Governance application. You can use these default guest interfaces for many of your resource blocks.

If you do need to create a new guest interface, these operations are provided by default:
  • Start
  • Stop
  • Provision
  • Deprovision
  • Cleanup
  • ModifySchedule
  • ModifyLease

Resource block component details

Each resource block contains these components:
Layers

The logical layer in the stack that this resource block belongs to. By default, Cloud Provisioning and Governance provides the layers. When you configure resource blocks, you can choose the one that relates to you.

Operations for each guest interface

As mentioned, each guest interface provides operations. For example, the most common operations for a virtual server are Provision, Deprovision, Start, Stop.

Input parameters for each operation

The input parameters hold values that the cloud provider uses, via CAPI, when operations are run. These parameters hold the information that the user selects while performing an operation, such as provisioning, on a stack.

For example, a user typically must specify the location, which is a datacenter, that a stack belongs in. The value that the user selects in the Location field is held in the Location parameter. The system takes this parameter, which is available by default for the virtual server resource block, and passes it to the CreateNode CAPI interface operation. The CreateNode interface operation tells the cloud provider to create (or provision) the actual virtual server.

Steps for each operation

Each operation requires a step to do the actual work. Each step calls a specific interface and method in CAPI, and passes along the input parameters required by that method. For example, the Provision operation on a virtual server provides one step to first connect and create a virtual machine, and another step to create the node in the cloud provider. Each step provides different input parameters. To connect and create a virtual machine, the cloud account, among many other parameters, is required. To create the node, the cloud account is not required.

You can add as many steps as needed for each operation. You can also use output attributes to pass values in attributes from one step to another step, or from steps in one operation to steps in a subsequent operation. For example, the Provision operation for a virtual server can provide an output attribute for the network interface ID and another for the node ID. When the cloud provider sends the response, the actual ID of the network and node are parsed out of the response and saved in the output attributes. Subsequent steps can then use the IDs to perform actions.

Response processors

Response processors tell the system what to do in the CMDB. When the cloud provider sends a response after an operation is run, the processor handles the response.

Note: These processors are scripts that are system includes. They are not MID Server script includes like the CAPI scripts that you can create to integrate with the cloud provider.
Figure 4. How components work together
How resource block components work together
Users can see catalog items, also called stacks, in the Cloud Catalog. A catalog item is based on a blueprint, which in turn is composed of resource blocks that are connected together.
  1. The user kicks off the process by requesting a stack. The request is the Provision operation in the system.
  2. The system runs the steps in order for the Provision operation for the resource blocks that comprise the stack.
  3. Each step calls CAPI to determine which method to run, while also passing in values for necessary parameters.
  4. CAPI interfaces with the API of the cloud provider to provision the actual resource.
Figure 5. Process flow when a resource is created in the cloud provider
Response process from the cloud provider
  1. The cloud provider provisions the resource and responds with JSON.
  2. The system parses the response inside the resource script in the resource block.
  3. The system updates the CMDB. When provisioning a new resource, the system creates a CI in the correct table.
  4. The new stack appears in the cloud user portal for the user to manage.

The Resource Blocks page

Manage resource blocks in the Resource Blocks page. Open the Cloud Admin portal, and then navigate to Design > Resource Blocks.

Figure 6. Resource Blocks page components
Resource block page and descriptions of the items in the page