chapter25.asciidoc

The Provisioning Dialog

So far in Part II we have looked at several ways in which the virtual machine provisioning process can be customised. We have seen how we can automate the selection of virtual machine name, decide where to place the virtual machine, and expand the state machine to insert our own provisioning workflow steps.

This chapter will look at how the initial dialog that launched the provisioning process can also be customised. We might want to do this to expand the options available to us, or to preconfigure and hide other dialog elements for certain groups of users.

The specification for the new virtual machine or instance is entered into the Provisioning Dialog that is displayed to the user in the WebUI. This dialog prompts for all of the parameters and characteristics that will make up the new VM, such as the name, number of CPUs, and IP address.

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 The hardware tab of the VM provisioning dialog).

Figure 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 provisioning into VMware or OpenStack, for example.

Dialog YAML

Each provisioning dialog is formatted from a large (900 line+) 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 ManageIQ, each of which provides the context sensitivity for the particular provisioning operation. They are found under the Automate → Customization menu, in the Provisioning Dialogs accordion.

Name	Description
miq_provision_amazon_dialogs_template	Sample Amazon Instance Provisioning Dialog
miq_provision_microsoft_dialogs_template	Sample Microsoft VM Provisioning Dialog
miq_provision_openstack_dialogs_template	Sample Openstack Instance Provisioning Dialog
miq_provision_redhat_dialogs_clone_to_vm	Sample RedHat VM Clone to VM Dialog
miq_provision_redhat_dialogs_template	Sample RedHat VM Provisioning Dialog
miq_provision_dialogs_clone_to_template	Sample VM Clone to Template Dialog
miq_provision_dialogs_clone_to_vm	Sample VM Clone to VM Dialog
miq_provision_dialogs_pre_sample	Sample VM Pre-Provisioning Dialog
miq_provision_dialogs	Sample VM Provisioning Dialog
miq_provision_dialogs_template	Sample VM Provisioning Dialog (Template)
miq_provision_dialogs-user	Sample VM Provisioning Dialog for User

The various dialogs contain values that are relevant to their target provider type (Amazon, OpenStack, Microsoft, VMware or RedHat), 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 a 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, customising 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 1GB, 2GB or 4GB (see Default memory size options).

Figure 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 customise 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 Creating a new profile instance).

Figure 3. Creating a new profile instance

The dialog_name field in the new profile should contain the name of our new dialog (see The dialog_name schema field value changed to the new profile name).

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

Testing the provisioning dialog

To test this we login 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 Expanded range of memory sizes).

Figure 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 customised.

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.