Naming method executed prior CatalogItemInitialization

Automate
#1

HiHo,
just recently I ran into the issue again, that the naming code is actually executed before CatalogItemInitialization populates the provisioning object with the user provided data. Also, during VM naming the requester is always EVM-SuperAdministrator.

I would like to understand why this part of Automate always runs prior to the actual Catalog item entry point. This way is confusing and requires the actual naming code to be put into a different stage of the provisioning state machine (I usually put it into CustomizeRequest which has the provisioning object fully populated).

Maybe this design would make more sense to me, if I would better understand the rational behind it. :wink:

Regards,
Christian

1 Like
#2

@cjung

I have the same pain. For most of our implementations the VM names are based at least partly on tags that are picked from the service dialog.

I also ended up putting things in PreProvision that checks for a default name and calls the naming state machine to get a new name. Unfortunately I then needed to interpret the indexing values and check for duplicate names. Essentially, I duplicated some of the underlying cfme code to do these checks.

In every enterprise I have worked we named the machines using a location designation and some signifier of dev/test/prod. Tags and CatalogItemInitialization seemed like the correct way to approach this, but perhaps others have a better idea.

Set vmname using service dialog
#3

I would like to see a response to this. I’m hoping that I’m not approaching naming correctly, but like @ewannema , the best solutions I’ve seen to this basically involve re-writing pieces of the automate engine.

As @cjung requested, I would love for someone to clarify the design.

#4

The naming logic is called by the service_template_provision_request as part of the provisioning profile. I think the provisioning profile is probably the right place to handle naming as you might want to assemble a name based on a user’s tags or group membership. In the case of services though I completely agree that this makes no sense to always be the EVM-SuperAdministrator profile.

The service Provisioning Entry Point (i.e. CatalogItemInitialization) is called by the service_template_provision_task which is instantiated after the request has been approved.

If you want to change the VM name from the service_template_provision_task then just set your intended hostname by overriding the ruby symbols :vm_target_name (and :vm_target_hostname) which are created from the output side of the in-built VM naming code.

You could either name your dialog element option_0_vm_target_name, or make a small edit to CatalogItemInitialization to update the symbol, e.g.

# Get options_hash
options_hash = get_options_hash(dialog_options)
# Assemble my own VM name
options_hash[:vm_target_name] = my_vm_name

…but as @ewannema noted you’d then have to check for duplicate VM names manually or risk a “[MiqException::MiqProvisionError]: A VM with name: [xxxyyy] already exists’)]” message.

1 Like
Generating unique VM names during provisioning
#5

I know this post is old but just thought for anyone else who stumbles upon this that until an upstream RFE is put in place my tested and used in production solution can be found here https://github.com/rhtconsulting/miq-Utilities/blob/master/Automate/RedHatConsulting_Utilities/Service/Provisioning/Naming.class/methods/set_vm_names.rb

2 Likes