Request from Provisioning Dialog or Service catalog?

Support
#1

Hello, how do I tell whether a provisioning request was made from a provisioning dialog (compute > infra > vm > Lifecycle) or a service catalog (services > catalog)?

Thanks

vCenter Cluster Placement
#2

Dan,

This would be a good place to start, https://pemcg.gitbooks.io/mastering-automation-in-cloudforms-4-2-and-manage/content/requests_and_tasks/chapter.html. Specifically the Request and Task Objects section talks about which type of Request object and Task object you will get depending on how automate was entered into.

Blue skies,
Ian

#3

So the following will work, when methods are being run at / Infrastructure / VM / Provisioning / StateMachines / VMProvision_VM / which is a task stage?

case $evm.root[ā€˜vmdb_object_typeā€™]
when ā€˜miq_provisionā€™ # called from a VM provision workflow
code for (compute > infra > vm > Lifecycle)
when 'service_template_provision_taskā€™
code for (services > catalog)

Thanks

#4

Tried it and it all looks good. Thanks Ian!

#5

Further testing shows I didnt quite get it right. I am trying to make the distinction at / Infrastructure / VM / Provisioning / StateMachines / VMProvision_VM stage. By this stage we no loner have a request object, its all task? The switch between request and task happens once approval is complete, right. Both Service Catalog and Provision Dialog has task objects of miq_provision

What I am trying to do is configure the NICs for the requested VM (vCenter), this only needs to happen if the request came via Service Catalog. The method gets called from the Provision VM from Template (template) in the above path. It works for requests from the service catalog, but not provisioning dialog (the questions and thus options asked in service catalog arenā€™t done here, dont want to really). Was hoping to just add an assertion or similar check to only execute methoid if the request was from service catalogā€¦

#6

Hi @dan
You can compare $evm.root[ā€˜vmā€™] for two type of provisioning. I do it by object_walker. For Lifecycle provisioning $evm.root[ā€˜vmā€™].miq_provision.miq_provision_request.source_type is ā€˜templateā€™ and for Service provisioning is ā€˜ServiceTemplateā€™.

#7

Hi @igortiunov thanks for the pointers. I have attached an obj_rd for the method. I am still learning about how to use obj_walker/rd, as per here. That topic got a bit distractedā€¦ Does all objects/attrib/methods/etc listed in the output mean they are available for the method where obj_walker was called? Also how do I construct the path to it, from what I see in the output.

For instance I tried adding ā€œif $evm.root[ā€˜miq_provisionā€™].miq_provision_request.source_type = ā€˜ServiceTemplateā€™ thenā€ to the method but its failing with method_missing, as per attached.

Also tried your ā€œ$evm.root[ā€˜vmā€™].miq_provision.miq_provision_request.source_typeā€ but didnā€™t work either.

Thanks again, appreciate the help.autolog_checkfor.log (3.8 KB)
objwalker_rd_igor.log (135.9 KB)

#8

OK, looks like a syntax error on my sideā€¦

""if $evm.root[ā€˜miq_provisionā€™].miq_provision_request.source_type == ā€˜ServiceTemplateā€™

Omitted a ā€œ=ā€ in the statement.

Still wondering about how to use obj_walker/rdā€¦ looks like what we see in the outputs are useable in the method it was runā€¦ or are there exceptions?

thanks

#9

Hi @dan

For object_walker it is. You can use its output from automation because it just show you object structure and its methods. In turn, the objects do not change during their lifetime. Can only change virtual columns.

For simple inspection of current object from automate I often use InspectMe method and his methods for investigation. For example to display the current attributes and associations I can add one line to automation code:

$evm.root.attributes.sort.each { |k, v| $evm.log("info", "  Attribute - #{k}: #{v}") }

or

$evm.root.associations.sort.each { |assc| $evm.log("info", "    Associations - #{assc}") }
1 Like
#10

Nice one. Thanks igortiunov.

#11

All of the objects that object_walker traverses should be accessible from your method (itā€™s walking the same $evm.root structure that your method sees). If you look at the output that you posted itā€™s printed the automation instance hierarchy, showing where your method fits under $evm.root, i.e.

 --- automation instance hierarchy ---
 /ManageIQ/System/Process/AUTOMATION  ($evm.root)
 |    /ManageIQ/infrastructure/VM/Lifecycle/Provisioning
 |    |    /ManageIQ/Infrastructure/VM/Provisioning/Profile/EvmGroup-super_administrator
 |    |    /CPA/Infrastructure/VM/Provisioning/StateMachines/VMProvision_vm/template
 |    |    |    /ManageIQ/Infrastructure/VM/Provisioning/StateMachines/Methods/CustomizeRequest
 |    |    |    /ManageIQ/Infrastructure/VM/Provisioning/Placement/default
 |    |    |    /CPA/Infrastructure/VM/Reconfigure/StateMachines/Add_Nics
 |    |    |    |    /CPA/Infrastructure/VM/Reconfigure/Methods/Add_Nics  ($evm.parent)
 |    |    |    |    |    /CPA/ObjectWalker/ObjectWalker/objectwalker  ($evm.object)

If youā€™re interested there was a presentation entitled ā€œInvestigative Debugging of ManageIQā€ at last years summit that discusses some uses of several tools including object_walker. The YouTube recording is here: https://www.youtube.com/watch?v=PbnYj4lXDn8&list=PLQAAGwo9CYO-4tQsnC6oWgzhPNOykOOMd&index=22

There are links to the demos here: http://manageiq.org/blog/2016/06/presentation-slides-and-demo-videos-from-manageiq-design-summit/

Cheers,
pemcg

1 Like
#12

Awesome, thanks Pete!