VMware vRealize Automation
kitchen-vra is a Test Kitchen driver for vRealize Automation that runs against the VMware vRealize Automation [V8.x] API.
Setting Driver Configuration
The VMware vra driver for Test Kitchen includes many configuration options that can be set globally in the driver section of your kitchen.yml config file or within each platform configuration. Global settings apply to all platforms in the
kitchen.yml, while platform level driver configuration is applied to only those platforms and override globally set configuration options. Even if you use platform level configuration options, it’s a good idea to specify the driver you use to use globally.
Example Global Driver Option
This configuration sets the driver to
vra and then sets the
some_config configuration to true.
driver: name: vra some_config: true
Example Platform Driver Option
This configuration sets the driver to
vra globally and then sets the
some_config configuration to true for just
driver: name: vra platforms: - name: ubuntu-20 driver: some_config: true
Driver Configuration Options
Specifying login credentials
Edit your .kitchen.yml file to set the driver to ‘vra’ and supply your login credentials:
driver: name: vra username: firstname.lastname@example.org password: mypassword tenant: mytenant base_url: https://vra.corp.local verify_ssl: true
If you want username and password to be prompted, remove usename and password in your .kitchen.yml as shown below:
driver: name: vra tenant: mytenant base_url: https://vra.corp.local verify_ssl: true
If you don’t want to explicitly specify username and password in the kitchen.yml, you have an option to set it in the environment variable as
export VRA_USER_NAMEemail@example.com' export VRA_USER_PASSWORD='mypassword'
id of the catalog item from which you are requesting the deployment
id of the project
specifies the OS image for a VM
specifies the CPU count and RAM of the machine
You can specify or skip providing a version. If version is not provided the latest version will be fetched automatically and used.
catalog_id , catalog_name
Either a catalog_id or a catalog_name is required for each platform. If both catalog_id and catalog_name are mentioned in .kitchen.yml then catalog_name would be used to derive the catalog_id and this catalog_id would override the catalog_id being passed in .kitchen.yml. In the below example as can be seen we are using catalog_id for centos6 driver while catalog_name for the centos7 driver just to demonstrate that we can use either of the two.
platforms: - name: centos6 driver: catalog_id: e9db1084-d1c6-4c1f-8e3c-eb8f3dc574f9 project_id: 6ba69375-79d5-42c3-a099-7d32739f71a9 image_mapping: SQL 2016 flavor_mapping: Small version: 1 - name: centos7 driver: catalog_name: my_catalog_name project_id: 6ba69375-79d5-42c3-a099-7d32739f71a9 image_mapping: VRA-nc-lnx-ce8.4-Docker flavor_mapping: Small
amount of time, in seconds, to wait for a vRA request to complete. Default is 600 seconds.
Number of times to retry the “waiting for server to be ready” check. In some cases, this will error out immediately due to DNS propagation issues, etc. Setting this to a number greater than 0 will retry the
wait_until_ready method with a growing sleep in between each attempt. Defaults to 1. Set to 0 to disable any retrying of the
the Business Group ID to list as the owner. This is required if the catalog item is a shared/global item; we are unable to determine the subtenant_id from the catalog, and vRA requires it to be set on every request.
the Business Group Name as the owner. This can be passed instead of subtenant_id and would act as a more friendly name. subtenant_id would be internally retrieved based on the provided subtenant_name. In case both subtenant_id and subtenant_name are passed, subtenant_name would take the precendence and would try to retrieve subtenant_id based on subtenant_name passed.
path to the SSH private key to use when logging in. Defaults to ‘~/.ssh/id_rsa’ or ‘~/.ssh/id_dsa’, preferring the RSA key. Only applies to instances where SSH transport is used; i.e., does not apply to Windows hosts with the WinRM transport configured.
false. Set to
true if vRA doesn’t manage vm ip addresses. This will cause kitchen to attempt to connect via hostname.
nil. Set to your domain suffix, for example ‘mydomain.com’. This only takes effect when
use_dns == true and is appended to the hostname returned by vRA.
a hash of other data to set on a catalog request, most notably custom properties. Allows updates to existing properties on the blueprint as well as the addition of new properties. Each key in the hash is the property name, and the value is a another hash containing the value data type and the value itself. It is possible to use a
~ to add nested parameters.
driver: name: vra username: firstname.lastname@example.org password: <%= ENV['VRA_USER_PASSWORD'] %> tenant: example.com project_id: xxxxx-xxxxxxxx base_url: https://example.com verify_ssl: false image_mapping: VRA-nc-lnx-ce8.4-Docker flavor_mapping: Small version: 1 provisioner: name: chef_infra platforms: - name: centos driver: catalog_id: 97aac381-327d-3b5c-ad93-e18fc855045e extra_parameters: mycustompropname: type: string value: largevalue Vrm.DataCenter.Location: type: string value: Prod suites: - name: default run_list: - recipe[my_cookbook::default]