Set vmname using service dialog


#1

Hi, I’m trying to set vmname using service dialog, but I can’t find any objects to set it.
There are a way to execute the method vmname at this time?


#2

@francisconp

A few of us have had problems with naming of services. It gets especially complex if you want things to work with Lifecycle Provisioning and Service Catalogs.

Here is some background on my problem: Naming method executed prior CatalogItemInitialization

In my code I run CatalogItemInitialization as the entry point of the Catalog Item and then in vmware_CustomizeRequest I check to see if the name is the default value (I actually use “default”). If it is, then I call out to the naming method to find a good name.

Used this way particular names can be specified in a separate Catalog Item or via Lifecycle provisioning without being overwritten. If the name is still a version of default in vmware_CustomizeRequest then the naming method is called again as it should have the appropriate information at this point.

Given all of this, I am not extremely happy with this solution: it is just something that I have found a way to make work.

The portion of the vmname method which returns a “default” if the appropriate information is not available when it is called. This would happen when a service provision is called. Note that I return default with 4 digits because the names get used up and if the requirement for unique names is set then things may break.

Some of the code from vmware_CustomizeRequest that figures out if the name is not yet set appropriately and tries to update it.


#3

I set my vm_name in catalogiteminitialization from the dialog. Look at the get_vm_name section here:

https://github.com/ramrexx/CloudFormsPOC/blob/master/Automate/CloudFormsPOC/Service/Provisioning/StateMachines/Methods.class/methods/catalogiteminitialization.rb


#4

Hi,

Sorry for resurrecting an old thread, but it has answered a few questions for me. I’ve used Ewannema’s mods to CustomizeRequest as a basis, but I am experimenting with ‘vm_prefix’. I have this:

# Get provisioning object
prov = $evm.root["miq_provision"]

$evm.log("info", "Provisioning ID:<#{prov.id}> Provision Request ID:<#{prov.miq_provision_request.id}> Provision Type: <#{prov.type}>")

prov.set_option(:vm_name, "changeme")
prov.set_option(:vm_prefix, "method_name")

vm_name_object = $evm.instantiate('/Cloud/VM/Provisioning/Naming/default')
vm_name = vm_name_object['vmname']

$evm.log(:info, "The new VM name is '#{vm_name}'")
prov.set_option(:vm_target_name, vm_name)
prov.set_option(:vm_target_hostname, vm_name)
prov.set_option(:vm_name, vm_name)

My eventual goal is to set ‘vm_prefix’ according to values set in a Dialog rather than hardcode it as it is now. I wanted to use ‘vm_prefix’ because I was assuming that there would be some uniqueness testing built into it, but as Ewannema is looping and checking for a unique name I guess my assumption is wrong?

Also, the code doesn’t seem to work very well in that the variable ‘$n{3}’ does not get resolved and I end up with an error like this:

[----] I, [2015-08-12T15:27:50.585067 #18748:74bea4]  INFO -- : Q-task_id([miq_provision_1000000000346]) Invoking [inline] method [/ManageIQ/Cloud/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status] with inputs [{"status"=>"[MiqException::MiqProvisionError]: A VM with name: [method_name$n{3}] already exists"}]

That seems strange to me because I have a default copy of ‘/Cloud/VM/Provisioning/Naming/default’.

So, my questions are:

  1. Why does ‘$n{3}’ not work as expected?
  2. Will using ‘vm_prefix’ safeguard me from duplicate vm_names?
  3. If the answer to #2 is ‘no’ should I put the uniqueness testing into ‘/Cloud/VM/Provisioning/Naming/default’ instead of ‘Cloud/VM/Provisioning/StateMachines/Methods/amazon_CustomizeRequest’ - it seems to make more sense to me?

Thanks in advance for any assistance,
Rotty

PS, I’m using CloudForms 5.4.0.5 (with a patch from PR #3052)


#5

Hello,

I believe the $n{x} token substitution only happens in the product if the name is assigned as part of the initial request creation. It is a little bit of magic there.

To correct this in my implementation I re-implemented the token substitution in the automate method so if the name were reassigned then the automatic numbering could happen.

You can see the code for this in the gist mentioned above starting at line #11.