Service provision dialogs interpolated in instance schema


#1

Attempting to provide the service name to an Ansible tower job template that is run during miq_provisioning, but I cannot find the value in that object during provisioning. It appears that it occurs after the service completes provisioning, and so vm.service.name isn’t available till after service prov completes. Either way, I’m wondering if on my job instance’s schema, can I use service=${/#evm.root[‘dialog_service_name’]}? I don’t need someone familiar with the Ansible integration, though it might help, but someone more familiar with rails and/or how to access a key from the root object in the instance schema.

Sorry if any of my terminology needs clarification, still learning.


#2

@corymerrill From the gitter chat you mentioned using build_vm_provision_request.

@ramrexx Can you help out here?


#3

@ramrexx @gmccullough I have no issues setting my entry point to CatalogItemInitialization. I do not believe any of the “enhancements” from the CF Essentials is necessary. I just cannot find any object from the miq_provision that contains the service that started the build. I I could interpolate something in the schema value to get a value from ws_values…

Another idea(but don’t know how to implement as of yet) would be adding it as a tag, since tags will pass in the metadata portion of the inventory sync in Tower from MIQ. My playbooks could then reference the service name from that location. Is there a simple way to have my service_name dialog become a tag also? is it as simple as tag_0_service_name?


#4

Cory,
All dialog parameters are automatically get shoved into the miq_provision options hash. so if you are passing in service_name from your dialog, during the miq_provision state machine you would do something like this to get the variable:

task = $evm.root['miq_provision’
ws_values = task.options.fetch(:ws_values, {})
svc_name = ws_values[:dialog_service_name] || task.get_option(:dialog_service_name)
$evm.log(:info, “svc_name: #{svc_name}”)

if you are still stuck and want to find what and where your variable is you can also use this to log everything in the options hash:

task.options.each { |k,v| $evm.log(:info,“Provisioning Option Key:<#{k.inspect}> Value:<#{v.inspect}>”) }

I hope this helps


#5

Hi Cory

The service object is the ‘destination’ association from the provisioning task’s parent service_template_provision_task.

You should also be able to get the service name by following the associations between the objects. Something like (untested):

$evm.root['miq_provision'].miq_request_task.destination.name

Cheers,
pemcg


#6

@ramrexx This did help me find the value, though a little bit funky.
I needed to have a dialog_tag_0_service_name (which would allow for Ansible Tower inventory sync to bring it over in the metadata as a tag. This worked for the Ansible piece, but the service naming (if not automatically determined) needed to come from dialog_service_name, so the service would get named based on users choice. (I just wrote a couple lines in dialog_parser to check and set values).

Been travelling last few days, so I haven’t tested everything to make sure it is functioning as I intended. I’ll likely go back and clean it up once I get more familiarity and/or a better way to accomplish what I’m attempting to do.

In the end, the service name will be used to generate a directory services security group. This will be created through ADEdit, add the user who requested to that security group, attach the group to the server(win or linux). Just means that all 5 servers together will have 1 access group by default to represent the owner(s).


#7

@pemcg How would I embed that into an automate instance field? I had assumed miq_priviosn.miq_reqeust_task.destnation.name, but no dice.

Does that make sense?


#8

Did anyone ever find a solution to Cory’s problem? I am needing the same thing and cannot figure out the proper syntax to get the dialog item interpolated.

Thanks