Setting VM name based on Dialog for Service Provision of Catalog Item


#1

Hi all

I am struggling to get my head around this problem - I want to be able to set the name of a VM provisioned from a Service Catalog Item.

I have reviewed a number of posts and articles on this topic and whilst they all contain valid and interesting points, I haven’t been able to pull these together to make a working solution.

My issues is as follows:

Most of my automate methods, classes and state machines are as they come “out of the box”. I have created my own domain to modify some of the state machines but for the most part they are as they come.

When I provision a VM from the Service Catalog I see that there is a Method being run that sets the VM name:

ManageIQ / Infrastructure / VM / Provisioning / Naming / vmname

I can see the effects of this in the automate.log file:

[----] I, [2015-05-21T10:36:11.777805 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) Following Relationship [miqaedb:/infrastructure/VM/Provisioning/Profile/EvmGr
oup-super_administrator#get_vmname]
[----] I, [2015-05-21T10:36:11.841878 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) Updated namespace [miqaedb:/infrastructure/VM/Provisioning/Profile/EvmGroup-s
uper_administrator#get_vmname  ManageIQ/infrastructure/VM/Provisioning]
[----] I, [2015-05-21T10:36:11.871901 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) Following Relationship [miqaedb:/Infrastructure/VM/Provisioning/Naming/Defaul
t#create]
[----] I, [2015-05-21T10:36:11.936960 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) Updated namespace [miqaedb:/Infrastructure/VM/Provisioning/Naming/Default#cre
ate  ManageIQ/Infrastructure/VM/Provisioning]
[----] I, [2015-05-21T10:36:11.943251 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) Updated namespace [Infrastructure/VM/Provisioning/Naming/vmname  ManageIQ/Inf
rastructure/VM/Provisioning]
[----] I, [2015-05-21T10:36:11.948655 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) Invoking [inline] method [ManageIQ/Infrastructure/VM/Provisioning/Naming/vmna
me] with inputs [{}]
[----] I, [2015-05-21T10:36:11.949384 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) <AEMethod [ManageIQ/Infrastructure/VM/Provisioning/Naming/vmname]> Starting
[----] I, [2015-05-21T10:36:12.276919 #15290:d354140]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) <AEMethod vmname> Detected vmdb_object_type:<miq_provision>
[----] I, [2015-05-21T10:36:12.290048 #15290:d354140]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) <AEMethod vmname> VM Name: <UbuntuDHCP>
[----] I, [2015-05-21T10:36:12.300212 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) <AEMethod [ManageIQ/Infrastructure/VM/Provisioning/Naming/vmname]> Ending
[----] I, [2015-05-21T10:36:12.300317 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) Method exited with rc=MIQ_OK
[----] I, [2015-05-21T10:36:12.300943 #15290:85e008]  INFO -- : Q-task_id([service_template_provision_request_1000000000030]) Followed  Relationship [miqaedb:/Infrastructure/VM/Provisioning/Naming/Defaul
t#create]

However this is run before the Provisioning Entry Point for the Catalog Item I created, and as such it does not have access to the custom dialog fields I created for this item. Any attempt to insert code such as:

dialog_vm_name = $evm.root['dialog_vm_name']
$evm.log("info","VM name = #{dialog_vm_name}")

Into this method results in a null object error which is to be expected if I am understanding the state machines correctly.

However if I attempt to modify the VM Name in the Provisioning state machine I can access the dialog field data using code as shown above, however I don’t have access to the $evm.root['miq_provision'] object so I can’t see how to set or change the VM name.

At present I am struggling to understand how the state machines hang together and how data is passed between them. Specifically I’d like to know how/where I should be obtaining the field data from the dialog, and then how I apply it to the VM before it is provisioned.

I am not worried about duplicate name exceptions at this stage - I will rectify that once I can get the basic code working and there seem to be lots of good examples of this out there.

Thanks in advance for any and all help - please let me know if further detail or clarity is required.

J


#2

You need to copy Infrastructure -> Provisioning -> Clone VM from template statemachine class to your own namespace, create own instance + method and add it to a workflow.

Script is something like. and your dialog should have hostname textbox which ‘hostname’ as a attribute.

prov = $evm.root[“miq_provision”]
hostname = dialog_options[‘dialog_hostname’]

prov.set_option(:vm_target_name, “#{hostname}”)
prov.set_option(:linux_host_name, “#{hostname}”)
prov.set_option(:vm_target_hostname, “#{hostname}”)
prov.set_option(:host_name, “#{hostname}”)

$evm.log(“info”, “Automate Method Ended”)
exit MIQ_OK

Hope it works!


#3

in your service dialog you should be using vm_target_hostname to set the name


#4

Hi there,

Sorry for the delayed response - thanks to both of you for your suggestions.

I’m afraid that using “vm_target_hostname” in the service dialog makes no difference - the new hostname is not picked up by any of the existing state machines or methods.

Regards the Clone VM suggestion - I don’t have such an entry under Infrastructure->Provisioning. If I check the automation.log I can see that at one point we are using the following method:

/Service/Provisioning/StateMachines/ServiceProvision_Template/clone_to_service

However I can’t find the Clone VM method specifically. Any suggestions on where to look - I’ve been tracing out which state machine the appliance is following by default and at one point it is following this state machine:

/Infrastructure/VM/Provisioning/StateMachines/VMProvision_vm/template

Does that help us on where to look?

Thanks again for all your help so far!

J


#5

Additional question that I think I should have asked right back at the beginning of this thread…

What is the correct Entry Point to set for the Catalog Item when I create it? This (if I understand correctly) will determine the path taken through the state machines, and as a result I am guessing that if I set this incorrectly in the first place this will thus have a knock on effect on how the VM is created, customized (e.g. hostname set), and so on.

Please can someone advise? Thanks!


#6

Which version of ManageIQ are you using?
Currently there is a bug in the CatalogItemInitialization method when it sets the vm_name from the dialog parameters.
We are in the process of fixing it.
To set the vm_name from the dialog you need to make the following 2 changes
(1) Point the Entry Point for your Service Item to be
Service/Provisioning/StateMachines/ServiceProvision_Template/CatalogItemInitialization
(2) Create a dialog with an Element Name of vm_name


#7

Thanks @mkanoor - really appreciate your help.

In this instance I am using the Red Hat version of CloudForms - version 5.3.4 (latest stable release at the time of writing). There are probably a lot of bugfixes in ManageIQ that haven’t made it into CloudForms - I don’t know how the release cycles track to be honest.

Anyway - I made the changes you suggest and the VM creation request fails. In the dialog (I created with a single textbox named vm_name as advised) I set the hostname to be “bob111” for testing purposes.

However in the automation.log I see the following:

[root@cf314 log]# grep -i error automation.log
[----] I, [2015-06-03T10:54:36.049195 #23544:3861598]  INFO -- : Q-task_id([service_template_provision_task_10]) <AEMethod check_provisioned> Service ProvisionCheck returned <error> for state <finished> and status <Error>
[----] I, [2015-06-03T10:54:36.136223 #23544:656008]  INFO -- : Q-task_id([service_template_provision_task_10]) Processed  State=[checkprovisioned] with Result=[error]
[----] W, [2015-06-03T10:54:36.136441 #23544:656008]  WARN -- : Q-task_id([service_template_provision_task_10]) Error in State=[checkprovisioned]
[----] I, [2015-06-03T10:54:36.137861 #23544:656008]  INFO -- : Q-task_id([service_template_provision_task_10]) In State=[checkprovisioned], invoking [on_error] method=[update_serviceprovision_status(status => '[MiqException::MiqProvisionError]: A VM with name: [test1] already exists')]
[----] I, [2015-06-03T10:54:36.187324 #23544:656008]  INFO -- : Q-task_id([service_template_provision_task_10]) Invoking [inline] method [ManageIQ/Service/Provisioning/StateMachines/ServiceProvision_Template/update_serviceprovision_status] with inputs [{"status"=>"[MiqException::MiqProvisionError]: A VM with name: [test1] already exists"}]
[----] I, [2015-06-03T10:54:49.528930 #13983:61c22e8]  INFO -- : Q-task_id([service_template_provision_task_11]) <AEMethod check_provisioned> Service ProvisionCheck returned <error> for state <finished> and status <Error>
[----] I, [2015-06-03T10:54:49.544615 #13983:1037004]  INFO -- : Q-task_id([service_template_provision_task_11]) Processed  State=[checkprovisioned] with Result=[error]
[----] W, [2015-06-03T10:54:49.544812 #13983:1037004]  WARN -- : Q-task_id([service_template_provision_task_11]) Error in State=[checkprovisioned]
[----] I, [2015-06-03T10:54:49.545930 #13983:1037004]  INFO -- : Q-task_id([service_template_provision_task_11]) In State=[checkprovisioned], invoking [on_error] method=[update_serviceprovision_status(status => '[MiqException::MiqProvisionError]: A VM with name: [test1] already exists')]
[----] I, [2015-06-03T10:54:49.593376 #13983:1037004]  INFO -- : Q-task_id([service_template_provision_task_11]) Invoking [inline] method [ManageIQ/Service/Provisioning/StateMachines/ServiceProvision_Template/update_serviceprovision_status] with inputs [{"status"=>"[MiqException::MiqProvisionError]: A VM with name: [test1] already exists"}]
[----] I, [2015-06-03T10:55:15.994293 #23544:38cecc4]  INFO -- : Q-task_id([miq_provision_12]) <AEMethod check_provisioned> ProvisionCheck returned <error> for state <finished> and status <Error>
[----] I, [2015-06-03T10:55:16.006696 #23544:656008]  INFO -- : Q-task_id([miq_provision_12]) Processed  State=[CheckProvisioned] with Result=[error]
[----] W, [2015-06-03T10:55:16.007013 #23544:656008]  WARN -- : Q-task_id([miq_provision_12]) Error in State=[CheckProvisioned]
[----] I, [2015-06-03T10:55:16.008093 #23544:656008]  INFO -- : Q-task_id([miq_provision_12]) In State=[CheckProvisioned], invoking [on_error] method=[update_provision_status(status => '[MiqException::MiqProvisionError]: A VM with name: [test1] already exists')]
[----] I, [2015-06-03T10:55:16.019479 #23544:656008]  INFO -- : Q-task_id([miq_provision_12]) Invoking [inline] method [ManageIQ/Infrastructure/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status] with inputs [{"status"=>"[MiqException::MiqProvisionError]: A VM with name: [test1] already exists"}]

The error is correct in that there is already a VM called “test1” - I created this on a previous test run. The name “test1” comes from the Catalog Item definition - I have to set a VM name on the “Request Info” tab of the “Create Service Catalog Item” page so I set this to test1 as ultimately this is only a placeholder - I want to change this during the actual provisioning process.

Is there somewhere I am fundamentally going wrong here?

Thanks again for all your help.


#8

Calling the element vm_name is something new that was added in 5.4 so it won’t work in your 5.3 environment.
Moreover the calling the element vm_name doesn’t extend to bundled services since a bundle could have multiple service items with different vm requests so just using vm_name would be ambiguous.

In 5.3 as well as in 5.4 you can use a slightly different approach to support bundles and multiple vm requests.

You would need to set a pair of element names to set the vm_name from the Service Dialogs. I tested this in 5.3 environment so hope it works in your environment.

I created a Service Dialog with 2 Text Box elements in it, only the Name is important the Label and Description can be anything you want. Type should be Text Box

The first text box element name is option_1_vm_name
The second text box element name is option_1_vm_target_name

If you had a second VM the names would be option_2_vm_name and option_2_vm_target_name

The Service Items have a Provisioning Entry Point this points to a state machine. In your case it should point to /ManageIQ/Service/Provisioning/StateMachines/ServiceProvision_Template/CatalogItemInitialization

With these changes you should be able to set the vm name from the Service Dialogs.


Documentation and worked examples for Automate features
#9

@mkanoor Thank you for this - this works for me. I am not using a bundle at this stage - just single VM’s - thus I only needed option_1_… in the dialog.

I notice that the VM is created with a name that matches option_1_vm_target_name. What is the purpose of the field option_1_vm_name?

Thanks for all your help so far!


#10

That was a mistake on my part. The vm_name is the original name from the request, the target_vm_name is the updated vm_name. So in your case you just need one element for the option_1_vm_target_name and nothing else.


#11

Hi,

Apologise for re-opening an old thread as I was running out of idea of how to provision VM with Service Catalog using CatalogItemInitialization. I have been searching the forum and try to follow the advices but I am not able to change the VM name from default one (set in Request Info) to the one I submitted from Service Catalog.

I had tried to name the element in various forms, e.g. vm_name, vm_target_name, option_0_target_name, option_1_target_name etc.
Although from the log I could see that upon executing get_vm_name in CatalogItemInitialization where vm_name was set correctly ( in prov.set_option(), where prov is instance of provision_task.miq_request_tasks ), at provision time it still pick up the default by miq_provision.get_option[:vm_name] .

When executing ConfigureChildDialog, the derived memory size has not been able to past to GrandChild (mio_provision) too. I had tried

  • t.set_dialog_option( ‘memory’, memory_size ) and
  • t.set_dialog_option( ‘dialog_memory’, memory_size )
    but neither would work.

It seems like someone had get this work, can you pls share what else need to be done? Thanks in advance.

Regards,
Casius.


#12

@casius
Is this a bundled service or a simple service with no bundles?


#13

Hi,

This is a simple service with no bundle. Thanks.

Cheers,
Casius.


#14

@casius
Which version are you using?

You mention that the get_vm_name function is being called according to the automation.log.
https://github.com/ManageIQ/manageiq/blob/master/db/fixtures/ae_datastore/ManageIQ/Service/Provisioning/StateMachines/Methods.class/methods/catalogiteminitialization.rb#L84
Can you log what the new_vm_name is and post a portion of the log.

You can copy the catalogiteminitialization method into a new domain and make the changes and rerun your provision.
Thanks,
Madhu


#15

Hi @mkanoor,

Thanks for your response. I am using Bonvinik at the moment but plan to move to Capabanca soon. For the time being I managed to get over the problem but changing get_vm_name() in CatalogItemInitialization:
prov.set_option(:vm_name, new_vm_name)

Thanks,
Casius.


#16

Hi,

Is there any way to change vm hostname(fqdn) after complete vm provisioning ?

I have another issue where i have to synchronize fqdn with CMDB.

fqdn = $evm.hostnames[0]

Please help and thanks in advance!

Regards,
Abhishek