11. Job Templates¶

11.1.1. OpenStack¶

The sample playbook below invokes the nova_compute Ansible OpenStack cloud module and requires credentials to do anything meaningful, and specifically requires the following information: auth_url, username, password, and project_name. These fields are made available to the playbook via the environmental variable OS_CLIENT_CONFIG_FILE, which points to a YAML file. This sample playbook loads the YAML file into the Ansible variable space.

OS_CLIENT_CONFIG_FILE example:

clouds:
  devstack:
    auth:
      auth_url: http://devstack.yoursite.com:5000/v2.0/
      username: admin
      password: your_password_here
      project_name: demo

Playbook example:

- hosts: all
  gather_facts: false
  vars:
    config_file: "{{ lookup('env', 'OS_CLIENT_CONFIG_FILE') }}"
    nova_tenant_name: demo
    nova_image_name: "cirros-0.3.2-x86_64-uec"
    nova_instance_name: autobot
    nova_instance_state: 'present'
    nova_flavor_name: m1.nano

    nova_group:
      group_name: antarctica
      instance_name: deceptacon
      instance_count: 3
  tasks:
    - debug: msg="{{ config_file }}"
    - stat: path="{{ config_file }}"
      register: st
    - include_vars: "{{ config_file }}"
      when: st.stat.exists and st.stat.isreg

    - name: "Print out clouds variable"
      debug: msg="{{ clouds|default('No clouds found') }}"

    - name: "Setting nova instance state to: {{ nova_instance_state }}"
      local_action:
        module: nova_compute
        login_username: "{{ clouds.devstack.auth.username }}"
        login_password: "{{ clouds.devstack.auth.password }}"

11.1.2. Amazon Web Services¶

Amazon Web Services cloud credentials are exposed as the following environment variables during playbook execution:

• AWS_ACCESS_KEY
• AWS_SECRET_KEY

All of the AWS modules will implicitly use these credentials when run via Tower without having to set the aws_access_key or aws_secret_key module options.

11.1.3. Rackspace¶

Rackspace cloud credentials are exposed as the following environment variables during playbook execution:

• RAX_USERNAME
• RAX_API_KEY

All of the Rackspace modules will implicitly use these credentials when run via Tower without having to set the username or api_key module options.

11.1.4. Google¶

Google cloud credentials are exposed as the following environment variables during playbook execution:

• GCE_EMAIL
• GCE_PROJECT
• GCE_PEM_FILE_PATH

All of the Google modules will implicitly use these credentials when run via Tower without having to set the service_account_email, project_id, or pem_file module options.

11.1.5. Azure¶

Azure cloud credentials are exposed as the following environment variables during playbook execution:

• AZURE_SUBSCRIPTION_ID
• AZURE_CERT_PATH

All of the Azure modules implicitly use these credentials when run via Tower without having to set the subscription_id or management_cert_path module options.

11.1.6. VMware¶

VMware cloud credentials are exposed as the following environment variables during playbook execution:

• VMWARE_USER
• VMWARE_PASSWORD
• VMWARE_HOST

The sample playbook below demonstrates usage of these credentials:

- vsphere_guest:
    vcenter_hostname: "{{ lookup('env', 'VMWARE_HOST') }}"
    username: "{{ lookup('env', 'VMWARE_USER') }}"
    password: "{{ lookup('env', 'VMWARE_PASSWORD') }}"
    guest: newvm001
    from_template: yes
    template_src: centosTemplate
    cluster: MainCluster
    resource_pool: "/Resources"
    vm_extra_config:
      folder: MyFolder

11.2.1. Creating a Survey¶

Clicking on Create Survey brings up the Add Survey window.

A survey can consist of any number of questions. For each question, enter the following information:

• Name: The question to ask the user
• Description: (optional) A description of what’s being asked of the user.
• Answer Variable Name: The Ansible variable name to store the user’s response in. This is the variable to be used by the playbook. Variable names cannot contain spaces.
• Answer Type: Choose from the following question types.
  • Text: A single line of text. You can set the minimum and maximum length (in characters) for this answer.
  • Textarea: A multi-line text field. You can set the minimum and maximum length (in characters) for this answer.
  • Password: Responses are treated as sensitive information, much like an actual password is treated. You can set the minimum and maximum length (in characters) for this answer.
  • Multiple Choice (single select): A list of options, of which only one can be selected at a time. Enter the options, one per line, in the Multiple Choice Options box.
  • Multiple Choice (multiple select): A list of options, any number of which can be selected at a time. Enter the options, one per line, in the Multiple Choice Options box.
  • Integer: An integer number. You can set the minimum and maximum length (in characters) for this answer.
  • Float: A decimal number. You can set the minimum and maximum length (in characters) for this answer.
• Default Answer: The default answer to the question. This value is pre-filled in the interface and is used if the answer is not provided by the user.
• Required: Whether or not an answer to this question is required from the user.

Once you have entered the question information, click Add Question to add the question.

A stylized version of the survey is presented, along with a New Question button. Click this button to add additional questions.

For any question, you can click on the Edit button to edit the question, the Delete button to delete the question, and click on the Up and Down arrow buttons to rearrange the order of the questions. Click Save to save the survey.

Click Save to save the survey.

11.2.2. Optional Survey Questions¶

The Required setting on a survey question determines whether the answer is optional or not for the user interacting with it.

Behind the scenes, optional survey variables can be passed to the playbook in extra_vars, even when they aren’t filled in.

• If a non-text variable (input type) is marked as optional, and is not filled in, no survey extra_var is passed to the playbook.
• If a text input or text area input is marked as optional, is not filled in, and has a minimum length > 0, no survey extra_var is passed to the playbook.
• If a text input or text area input is marked as optional, is not filled in, and has a minimum length === 0, that survey extra_var is passed to the playbook, with the value set to an empty string ( “” ).

11.2.3. Extra Variables¶

When you pass survey variables, they are passed as extra variables (extra_vars) within Tower. This can be tricky, as passing extra variables to a job template (as you would do with a survey) can override other variables being passed from the inventory and project.

For example, say that you have a defined variable for an inventory for debug = true. It is entirely possible that this variable, debug = true, can be overridden in a job template survey.

To ensure that the variables you need to pass are not overridden, ensure they are included by redefining them in the survey. Keep in mind that extra variables can be defined at the inventory, group, and host levels.

The following table notes the behavior (hierarchy) of variable precedence in Ansible Tower as it compares to variable precedence in Ansible.

Ansible Tower Variable Precedence Hierarchy (last listed wins)

11.2.4. Relaunching Job Templates¶

Another change for Ansible Tower version 2.4 introduced a launch_type setting for your jobs. Instead of manually relaunching a job, a relaunch is denoted by setting launch_type to relaunch. The relaunch behavior deviates from the launch behavior in that it does not inherit extra_vars.

Job relaunching does not go through the inherit logic. It uses the same extra_vars that were calculated for the job that is being relaunched.

For example, say that you launched a Job Template with no extra_vars which resulted in the creation of j1. Next, say that you changed the Job Template and all the extra_vars “{ “hello”: “world” }”. Relaunching j1 results in the creation of j2, but j2 will not have any extra_vars.

To continue upon this example, if you were to then launch the Job Template (with the extra_vars you added after the creation of j1), the relaunced job (j3) will include the extra_vars “{ “hello”: “world” }”. Relaunching j3, resulting in the creation of j4, would also include extra_vars “{ “hello”: “world” }”.

11.3.1. Passing Extra Variables to Provisioning Callbacks¶

Just as you can pass extra_vars in a regular Job Template, you can also pass them to provisioning callbacks. To pass extra_vars, the data sent must be part of the body of the POST request as application/json (as the content type). Use the following JSON format as an example when adding your own extra_vars to be passed:

'{"extra_vars": {"variable1":"value1","variable2":"value2",...}}'

(Added in Ansible Tower version 2.2.0.)

11.5.1. Add a new schedule¶

To create a new schedule click the button.

Enter the appropriate details into the following fields and select Save:

• Name (required)
• Start Date (required)
• Start Time (required)
• Local Time Zone (the entered Start Time should be in this timezone)
• UTC Start Time (calculated from Start Time + Local Time Zone)
• Repeat Frequency (the appropriate options displays as the update frequency is modified.)

The Details tab displays a description of the schedule and a list of the scheduled occurrences in the selected Local Time Zone.

There are several actions available for schedules, under the Actions column:

• Stop an active schedule or activate a stopped schedule
• Edit Schedule
• Delete schedule