Where did "destination" go?


#1

Hi there folks,

Based on Peter McGowan’s niffty diagram here: https://pemcg.gitbooks.io/introduction-to-cloudforms-automation/content/chapter17/images/service_objects_detailed.png

I’ve been using this approach in a method that worked in CloudForms 3.2:

provisioned_vms = $evm.root['service_template_provision_task'].destination.vms

provisioned_vms.each do |vm|
   #do stuff with the vm
end

However, on CloudForms 4.0 I’m now getting this error in the automate log:

[undefined method `destination' for nil:NilClass]
<code: provisioned_vms = $evm.root['service_template_provision_task'].destination.vms>:23:in `<main>'

Has .destination been removed from the service_template_provision_task? Or do I need to reference ‘destination’ some other way … maybe $evm.root[‘service_template_provision_task’][‘destination’].vms … if so, why?

Any ideas?


#2

@gmccullough can you review this question from @Stephen_McKay and forward to SME if necessary.


#3

@Stephen_McKay,

The message says that the destination method is being called on a nil object which mean $evm.root['service_template_provision_task'] is returning a nil.

You will need to take a look at what root attributes are being passed to the method.

Hope this helps.


#4

Hi @gmccullough

Yes it helps … but I’m still mystified. I’ve dumped the $evm.root attributes into the log to try to see what’s failing and why, but the $evm.root[‘object_type’] is service_template_provision_task …

 < AEMethod [/ManageIQ/Service/Provisioning/StateMachines/Methods/check_provisioned]> Starting
  < AEMethod check_provisioned> Listing Root Object Attributes:
  < AEMethod check_provisioned>         ae_next_state:
  < AEMethod check_provisioned>         ae_result: ok
  < AEMethod check_provisioned>         ae_state: checkprovisioned
  < AEMethod check_provisioned>         ae_state_retries: 1
  < AEMethod check_provisioned>         ae_state_started: 2016-04-18 04:51:11 UTC
  < AEMethod check_provisioned>         ae_state_step: main
  < AEMethod check_provisioned>         dialog_confirmation: t
   ...
 < AEMethod check_provisioned>         dialog_tag_1_mgd_svc: p_mgt_vwm
 < AEMethod check_provisioned>         miq_group: #< MiqAeMethodService::MiqAeServiceMiqGroup:0x00000009587f38>
 < AEMethod check_provisioned>         miq_server: #< MiqAeMethodService::MiqAeServiceMiqServer:0x000000095e3860>
 < AEMethod check_provisioned>         miq_server_id: 5000000000001
 < AEMethod check_provisioned>         object_name: CatalogItemInitialization
 < AEMethod check_provisioned>         request: clone_to_service
 < AEMethod check_provisioned>         service_template_provision_task: #< MiqAeMethodService::MiqAeServiceServiceTemplateProvisionTask:0x000000095c7b38>
 < AEMethod check_provisioned>         service_template_provision_task_id: 5000000000259
 < AEMethod check_provisioned>         tenant: #< MiqAeMethodService::MiqAeServiceTenant:0x000000095a4d40>
 < AEMethod check_provisioned>         user: #< MiqAeMethodService::MiqAeServiceUser:0x000000095ad5d0>
< AEMethod check_provisioned>         user_id: 5000000000013
< AEMethod check_provisioned>         **vmdb_object_type: service_template_provision_task**
< AEMethod check_provisioned> ===========================================
< AEMethod check_provisioned> Service ProvisionCheck returned <retry> for state <active> and status    < Ok >

The thing is - this used to work …


#5

@Stephen_McKay,

The logging here is from /ManageIQ/Service/Provisioning/StateMachines/Methods/check_provisioned which contains almost the exact same line that seems to be failing for you:

# Get current provisioning status
task = $evm.root['service_template_provision_task']
task_status = task['status']
result = task.statemachine_task_status

$evm.log('info', "Service ProvisionCheck returned <#{result}> for state <#{task.state}> and status <#{task_status}>")

Based on this log message the task variable is properly set to the service_template_provision_task object.

< AEMethod check_provisioned> Service ProvisionCheck returned <retry> for state <active> and status    < Ok >

Is your additional logic in the same method? If so can you try referencing the task variable? Otherwise, it would help if you could describe where in the automate model you are adding this logic.


#6

Hi Stephen

Have you ever used object_waker (https://github.com/pemcg/object_walker)? It’s an alternative way of dumping $evm.root and its child objects and their attributes, and can sometimes reveal more information.

Try either calling it as a relationship from a state in your state machine, or instantiate it from your code:

$evm.instantiate(’/path/to/object_walker’)

The output is written to automation.log, but it’s easier to extract and read using the companion object_walker_reader script (just copy this to your appliance and run it).

Hope this helps,
pemcg