Tabs and Input Fields

The provisioning dialog contains a number of tabs (Request, Purpose, Catalog, Environment, etc.), and a number of input fields per tab (see Figure 25-1).

Figure 25-1. The Hardware tab of the VM provisioning dialog

The provisioning dialog is context-sensitive, so a different set of input field options will be displayed when we’re provisioning into VMware or OpenStack, for example.

Dialog YAML

Each provisioning dialog is formatted from a large (900+ lines) YAML file, specifying the main tabs, dialogs, and fields to be displayed—for example:

---
:buttons:
- :submit
- :cancel
:dialogs:
  :requester:
    :description: Request
    :fields:
      :owner_phone:
        :description: Phone
        :required: false
        :display: :hide
        :data_type: :string
...
      :owner_email:
        :description: E-Mail
        :required: true
        :display: :edit
        :data_type: :string
 ...
   :purpose:
    :description: Purpose
    :fields:
      :vm_tags:
        :required_method: :validate_tags
        :description: Tags
        :required: false
        :options:
          :include: []
...
        :display: :edit
        :required_tags: []
        :data_type: :integer
    :display: :hide
    :field_order:
 ...
 :dialog_order:
- :requester
- :purpose

Dialog tabs and fields have four useful attributes that can be set:

• Hidden (:display: :hide)

• Visible (:display: :show)

• Editable (:display: :edit)

• Mandatory (:required: true)

Selection of VM Provisioning Dialog

There are a number of VM provisioning dialogs supplied out-of-the-box with CloudForms, each of which provides the context sensitivity for the particular provisioning operation (see Table 25-1). They are found under the Automate → Customization menu, in the Provisioning Dialogs accordion.

The various dialogs contain values that are relevant to their target provider type (Amazon, OpenStack, Microsoft, VMware, or Red Hat), and also to the operation type (clone from template, clone to template, or clone to vm).

The selection of VM provisioning dialog to display to a user depends on the dialog_name attribute in the provisioning group profile. The default dialog_name value for the .missing and EvmGroup-super_administrator profiles is:

${#dialog_name_prefix}_${/#dialog_input_request_type}

The two variables are substituted at runtime and provide the context sensitivity. The dialog_name_prefix value is determined by the vm_dialog_name_prefix method, which contains the lines:

dialog_name_prefix = "miq_provision_#{platform}_dialogs"
dialog_name_prefix = "miq_provision_dialogs" if platform == "vmware"

The dialog_input_request_type value is translated by the Rails class MiqRequestWorkflow to be the instance name of the VM provisioning state machine that we are using—that is, template, clone_to_vm, or clone_to_template.

So for a VM provision request from template into an RHEV provider, the dialog_name value will be substituted as follows:

miq_provision_redhat_dialogs_template

Group-Specific Dialogs

We can set separate provisioning dialogs for individual groups if we wish. As an example, the VMware-specific miq_provision_dialogs-user dialog presents a reduced set of tabs, dialogs, and input fields. The hidden tabs have been given default values, and automatic placement has been set to true:

      :placement_auto:
        :values:
          false: 0
          true: 1
        :description: Choose Automatically
        :required: false
        :display: :edit
        :default: true
        :data_type: :boolean

We can create per-group dialogs as we wish, customizing the values that are hidden or set as default.

Example: Expanding the Dialog

In some cases it’s useful to be able to expand the range of options presented by the dialog. For example, the standard dialogs only allow us to specify VM memory in units of 1 GB, 2 GB, or 4 GB (see Figure 25-2).

Figure 25-2. Default memory size options

These options come from the :vm_memory dialog section:

      :vm_memory:
        :values:
          '2048': '2048'
          '4096': '4096'
          '1024': '1024'
        :description: Memory (MB)
        :required: false
        :display: :edit
        :default: '1024'
        :data_type: :string

We sometimes need to be able to provision larger VMs, but fortunately we can customize the dialog to our own needs.

Copy the existing dialog

If we identify the dialog that is being used (in this example case, it is miq_provision_redhat_dialogs_template as we’re provisioning into RHEV using native clone), we can copy the dialog to make it editable (we’ll call the new version bit63_miq_provision_redhat_dialogs_template).

We can then expand the :vm_memory section to match our requirements:

      :vm_memory:
        :values:
          '1024': '1024'
          '2048': '2048'
          '4096': '4096'
          '8192': '8192'
          '16384': '16384'
        :description: Memory (MB)
        :required: false
        :display: :edit
        :default: '1024'
        :data_type: :string

Create a group profile

Now we copy the /Infrastructure/VM/Provisioning/Profile class into our own domain and create a profile instance for the group that we wish to assign the new dialog to, in this case Bit63Group-user (see Figure 25-3).

Figure 25-3. Creating a new profile instance

The dialog_name field in the new profile should contain the name of our new dialog (see Figure 25-4).

Figure 25-4. The dialog_name schema field value changed to the new profile name

Testing the provisioning dialog

To test this we log in as a user who is a member of the Bit63Group-user group and provision a virtual machine. If we navigate to the Hardware tab of the provisioning dialog, we should see the expanded range of memory options (see Figure 25-5).

Figure 25-5. Expanded range of memory sizes

Summary

In this chapter we’ve seen how the virtual machine provisioning dialog is used and how it can be customized.

We often create group-specific dialogs that contain a default set of provisioning options, and we can take advantage of this when we make an API call to provision a virtual machine as a particular user, for example. The user’s group profile will provide default values for the virtual machine, so we need only specify override values in our API call parameters.