Relationship between provisionning a service and provisionning a VM


#1

Where is defined the relationship between service provisionning and VM provisionning?

in the Service/Provisionning/Statemachines//ServiceProvision_Template/CatalogItemInitialization instance we can see a “call” to VMprovisionning machine:

provision /Service/Provisioning/StateMachines/Methods/Provision
and in Provision method:
$evm.root[“service_template_provision_task”].execute

and then?

Where is called the instance Infrastructure/VM/Provisionning/StateMachines/VMProvision_VM/Provision From VM ?

We would want to be able to choose between 2 instances “Provision From VM”, is it possible?


#2

Kind of :slight_smile:

The selection of VM provision state machine class is made from the VM provision group profile (in /Infrastructure/VM/Provisioning/Profile). There are 2 out-of-the-box profiles, EvmGroup-super_administrator and .missing. If you look at the state_machine field in one of these, the default value is VMProvision_${/#miq_provision.target_type} which for a VM provision translates to “VMProvision_VM”. The workflow then uses the instance name under this class that corresponds to the type of provisioning operation being performed, usually “template”.

So you can create an alternative state machine class (something like “VMProvision_VM_Custom”), that has its own instance under it called “template” (keep this the same name). Then you can create a new group profile for any of your custom user groups, that has the state_machine field hard-coded to your new “VMProvision_VM_Custom”. If a user that is a member of this custom group provisions a VM (either from a service or from Lifecycle -> Provision VM), then they will use the new VM provision state machine instance that you’ve created.

By the way you can follow the workflow through the service provisioning and VM provisioning state machines by tracing the “Following…Followed” message pairs in automation.log. This chapter shows an example: https://pemcg.gitbooks.io/mastering-automation-in-cloudforms-4-2-and-manage/content/log_analysis_during_service_provisioning/chapter.html. Under the section VM Provisioning Task you see the calls:

(miq_provision_119) Following [/Infra.../VM/Lifecycle/Provisioning#create]
  (miq_provision_119) Following [/Infra.../VM/Provisioning/Profile/Bit63_user#get_state_machine]
  (miq_provision_119) Followed [/Infra.../VM/Provisioning/Profile/Bit63_user#get_state_machine]

Hope this helps,
pemcg


#3

Thank you for you answer.
I can use a variable #VMProvision in the state_machine field?

{#VMProvision}_{/#miq_provision.target_type}

instead of VMProvision_${/#miq_provision.target_type}

so i am not obliged to create a new group user?


#4

Potentially, but where were you thinking of defining the variable?


#5

You could potentially set an options hash value :vm_provision_state_machine with the name of the state machine class that you want to use. If you wanted this to be dynamic you could even define a service dialog option with the name option_0_vm_provision_state_machine, that presented the user with a list of state machine names. Your profile state_machine field would then be something like:

${/#miq_provision.get_option(:vm_provision_state_machine)}

Caveat: untested but it might work :slight_smile:
pemcg