Hi
Yes you can associate a newly provisioned VM (provisioned using embedded Ansible) with the service, using the Ansible manageiq_vmdb role, as follows:
tasks:
- name: Get the service object
manageiq_vmdb:
href: "{{ manageiq.service }}"
register: service
- name: Get the VM object
manageiq_vmdb:
href: "vms/18"
register: vm
- name: Add the VM to the service
manageiq_vmdb:
vmdb: "{{ service }}"
action: add_resource
data:
resource:
href: "{{ vm.href }}"
The challenge is to get the new VM’s object id (in that example VMS/18
). For this you need to trigger a provider refresh via the API and detect the new VM. There’s an example of doing that in the following playbook (note that playbook hard-codes the provider_id to “21000000000002” - yours will almost certainly be different):
Regarding the Ruby versus Ansible argument, my own personal opinion is that the out-of-the-box Ruby-based VM and service provisioning “just works”, i.e. VMs are linked into services as you’d expect, and the workflow is thoroughly tested. The advantage of Ansible is where you don’t have existing Ruby skills to modify the workflow, and Ansible/yaml is certainly easier to learn and understand than Ruby for a novice.
I’d be wary of the claim for portability though, because you still tend to need to write ManageIQ-specific playbooks, as that example shows when using the manageiq_vmdb role to link the VM to the service, finding the new VM ID, etc.
hope this helps,
pemcg