Red Hat Bugzilla – Bug 1334679
Azure [NoMethodError]: undefined method `x_ms_meta_microsoftazurecompute_ostype'
Last modified: 2016-10-03 12:05:32 EDT
Description of problem: Provisioning from private Azure images fails with: INFO -- : Q-task_id([miq_provision_1000000000003]) Starting Phase <provision_error> ERROR -- : Q-task_id([miq_provision_1000000000003]) MIQ(ManageIQ::Providers::Azure::CloudManager::Provision#provision_error) [[NoMethodError]: undefined method `x_ms_meta_microsoftazurecompute_ostype' for #<Azure::Armrest::StorageAccount::BlobProperty:0x00000012c51cc0>] encountered during phase [prepare_provision] ERROR -- : Q-task_id([miq_provision_1000000000003]) /var/www/miq/vmdb/app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb:36:in `gather_storage_account_properties' Version-Release number of selected component (if applicable): cfme-vsphere-5.6.0.5-1.x86_64.vsphere.ova How reproducible: Steps to Reproduce: 1. Compute > Clouds > Instances 2. Lifecycle > Provision Instances 3. Complete and submit Actual results: Provisioning fails with [NoMethodError]: undefined method `x_ms_meta_microsoftazurecompute_ostype' Expected results: Additional info: Reviewing gather_storage_account_properties in app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb This line takes the first value which does not contain the x_ms_meta_microsoftazurecompute_ostype method. blob = storage_account.blobs("system", key).first A work around is iterate the blob object and use a VHD instance with x_ms_meta_microsoftazurecompute_ostype set. On my system: blob.name = Microsoft.Compute/Images/mytemplates/windows-img-dataDisk-0.c8a7a883-06ab-4787-93c7-6b24a34998eb.vhd nil blob.name = Microsoft.Compute/Images/mytemplates/windows-img-osDisk.c8a7a883-06ab-4787-93c7-6b24a34998eb.vhd x_ms_meta_microsoftazurecompute_ostype = Windows blob.name = Microsoft.Compute/Images/mytemplates/windows-img-vmTemplate.c8a7a883-06ab-4787-93c7-6b24a34998eb.json nil Full stack trace: ERROR -- : Q-task_id([miq_provision_1000000000009]) MIQ(ManageIQ::Providers::Azure::CloudManager::Provision#provision_error) [[NoMethodError]: undefined method `x_ms_meta_microsoftazurecompute_ostype' for #<Azure::Armrest::StorageAccount::BlobProperty:0x0000000bd26080>] encountered during phase [prepare_provision] [----] E, [2016-05-09T16:05:36.340729 #9416:74d998] ERROR -- : Q-task_id([miq_provision_1000000000009]) /var/www/miq/vmdb/app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb:42:in `gather_storage_account_properties' /var/www/miq/vmdb/app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb:51:in `prepare_for_clone_task' /var/www/miq/vmdb/app/models/miq_provision/state_machine.rb:14:in `prepare_provision' /var/www/miq/vmdb/app/models/miq_request_task/state_machine.rb:17:in `signal' /var/www/miq/vmdb/app/models/manageiq/providers/cloud_manager/provision/state_machine.rb:17:in `prepare_volumes' /var/www/miq/vmdb/app/models/miq_request_task/state_machine.rb:17:in `signal' /var/www/miq/vmdb/app/models/manageiq/providers/cloud_manager/provision/state_machine.rb:9:in `determine_placement' /var/www/miq/vmdb/app/models/miq_request_task/state_machine.rb:17:in `signal' /var/www/miq/vmdb/app/models/manageiq/providers/cloud_manager/provision/state_machine.rb:3:in `create_destination' /var/www/miq/vmdb/app/models/miq_request_task/state_machine.rb:17:in `signal' /var/www/miq/vmdb/app/models/miq_provision/state_machine.rb:4:in `run_provision' /var/www/miq/vmdb/app/models/miq_request_task/state_machine.rb:17:in `signal' /var/www/miq/vmdb/app/models/miq_provision_task.rb:15:in `do_request' /var/www/miq/vmdb/app/models/miq_request_task.rb:192:in `execute' /var/www/miq/vmdb/app/models/miq_queue.rb:347:in `block in deliver' /opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:89:in `block in timeout' /opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:34:in `block in catch' /opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:34:in `catch' /opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:34:in `catch' /opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:104:in `timeout' /var/www/miq/vmdb/app/models/miq_queue.rb:343:in `deliver' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:106:in `deliver_queue_message' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:134:in `deliver_message' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:152:in `block in do_work' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:146:in `loop' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:146:in `do_work' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:334:in `block in do_work_loop' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:331:in `loop' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:331:in `do_work_loop' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:153:in `run' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:128:in `start' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:21:in `start_worker' /var/www/miq/vmdb/app/models/miq_worker.rb:346:in `block in start' /opt/rh/cfme-gemset/gems/nakayoshi_fork-0.0.3/lib/nakayoshi_fork.rb:24:in `fork' /opt/rh/cfme-gemset/gems/nakayoshi_fork-0.0.3/lib/nakayoshi_fork.rb:24:in `fork' /var/www/miq/vmdb/app/models/miq_worker.rb:344:in `start' /var/www/miq/vmdb/app/models/miq_worker.rb:274:in `start_worker' /var/www/miq/vmdb/app/models/miq_worker.rb:154:in `block in sync_workers' /var/www/miq/vmdb/app/models/miq_worker.rb:154:in `times' /var/www/miq/vmdb/app/models/miq_worker.rb:154:in `sync_workers' /var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:52:in `block in sync_workers' /var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:50:in `each' /var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:50:in `sync_workers' /var/www/miq/vmdb/app/models/miq_server.rb:173:in `start' /var/www/miq/vmdb/app/models/miq_server.rb:264:in `start' /var/www/miq/vmdb/lib/workers/evm_server.rb:65:in `start' /var/www/miq/vmdb/lib/workers/evm_server.rb:92:in `start' /var/www/miq/vmdb/lib/workers/bin/evm_server.rb:4:in `<main>'
GregB - Can someone on the providers team take a look at this.
There must be some additional nuance to the configuration of Nick's private image. I'll work with him to better refine the conditions for which this fails. I found this from Dan Berger written a few months back dealing with snapshots and trying to determine the os type. https://github.com/ManageIQ/azure-armrest/wiki/Provisioning-a-VM-from-a-Snapshot
https://github.com/ManageIQ/manageiq/pull/8636
commit 073a8c5dfc411d0aec7de69460763a1abe4eb1f3 Author: Daniel Berger <dberger@redhat.com> Date: Wed May 11 13:33:56 2016 -0600 Use list_private_images to get source_uri, target_uri and OS information for storage account. Remove storage_account_name and storage_account_resource_group as they are no longer needed. Return storage_account_name and storage_account_resource_group and filter accordingly. Compare image URI vs source ems_ref. diff --git a/app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb b/app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb index 6e309fa..3814790 100644 --- a/app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb +++ b/app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb
This is still working as expected. Looked at code and it is what I would do. Moving to verified on 5.6.0.8
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1348