Debuging: finding why "[NoMethodError]: undefined method `[]"


#1

CF 4.2 (docker) with vmware 5.5:

When we deploy a service which in turn deploys a vpshere vm, we have a NoMethodError at the VM “Provisioning step”:

[----] I, [2017-02-14T11:53:14.410438 #395:385130] INFO – : Q-task_id([miq_provision_120]) Invoking [inline] method [/ManageIQ/Infrastructure/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status] with inputs [{“status”=>“Applied PreProvision Customizations”}]
[----] I, [2017-02-14T11:53:15.649454 #395:385130] INFO – : Q-task_id([miq_provision_120]) Invoking [inline] method [/ManageIQ/Infrastructure/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status] with inputs [{“status”=>“Creating VM”}]
[----] I, [2017-02-14T11:53:18.562888 #395:385130] INFO – : Q-task_id([miq_provision_120]) Invoking [inline] method [/ManageIQ/Infrastructure/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status] with inputs [{“status”=>“Creating VM”}]
[----] I, [2017-02-14T11:53:21.557904 #395:385130] INFO – : Q-task_id([miq_provision_120]) Invoking [inline] method [/ManageIQ/Infrastructure/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status] with inputs [{“status”=>“Creating VM”}]
[----] I, [2017-02-14T11:53:22.075570 #403:385130] INFO – : Q-task_id([service_template_provision_task_118]) Invoking [inline] method [/ManageIQ/Service/Provisioning/StateMachines/ServiceProvision_Template/update_serviceprovision_status] with inputs [{“status”=>“Creating Service”}]
[----] I, [2017-02-14T11:53:36.081155 #403:385130] INFO – : Q-task_id([service_template_provision_task_119]) Invoking [inline] method [/ManageIQ/Service/Provisioning/StateMachines/ServiceProvision_Template/update_serviceprovision_status] with inputs [{“status”=>"[NoMethodError]: undefined method []"}] [----] I, [2017-02-14T11:54:26.067618 #403:385130] INFO -- : Q-task_id([service_template_provision_task_118]) Invoking [inline] method [/ManageIQ/Service/Provisioning/StateMachines/ServiceProvision_Template/update_serviceprovision_status] with inputs [{"status"=>"[NoMethodError]: undefined method[]"}]
[----] I, [2017-02-14T11:54:27.870694 #395:385130] INFO – : Q-task_id([miq_provision_120]) Invoking [inline] method [/ManageIQ/Infrastructure/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status] with inputs [{“status”=>"[NoMethodError]: undefined method `[]"}]

The values in the instance for fields Provisioning and checkprovisioned (value, on exit, on error etc …) are standard ones from MIQ domain ‘Provision VM from Template’

I am unable to find problem origin , what missing method it’s talking about: is there a procedure to find it?

Any ideas?


#2

I’m curious what you are using as a Provisioning Entry Point for your Service Item.


#3

@tinaafitz Any thoughts on this one?


#4

Hi @gquentin,

I suspect the VM provisioning is failing in the check provisioned state and the message you’re seeing is actually the root object ae_reason value.

The checkprovisoned on_error => update_serviceprovision_status(status => ‘${/#ae_reason}’).

The VM provision failure percolates up to the Service provision, which has a similar checkprovisioned on_error => update_serviceprovision_status(status => ‘${/#ae_reason}’)

Are you able to successfully provision that VM using VM provisioning with the same values?
If so, can you send the automation.log and evm.log showing the complete Service provisioning to me at tfitzger@redhat.com?

Regards,
Tina


#5

We have found the root cause: in previous states (integration infoblox), where we set network adapter with prov.set_network_adapter and prov.set_nic_settings , the first network adapter (index 0) was not well filled.

And it had consequences in the provisionning state.

It was very difficult to find the root cause (we made hazardous changes to detect it because logs information are not enough).

Could it be possible to have logs which target better root causes?


#6

Hi @gquentin,

I know it can be really difficult to determine the problem root cause from the logs.
We’ve recently done some work to help with problem determination:

  • Enhanced Messaging: We added enhanced messages to the lifecycle state machines. Detailed messages displayed in the Request ‘last message’ column include the server, state, step, retry number, message and more.
  • Error Notifications: We added error notifications to our lifecycle state machines. These notifications are generated any time the state machine fails.

One suggestion that might help you is to copy some/all of the check_provisioned Automate methods into a writable domain and add more log messages for the error condition.

For example, our /Infrastructure/VM/Provisioning/StateMachines/Methods/check_provisioned method has a single log message:

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

Additional logging here could help make errors more obvious in the logs.

Regards,
Tina