Hide Forgot
Created attachment 1221521 [details] err Description of problem: Version-Release number of selected component (if applicable): 5.7.0.11-rc1.20161115160629_46cf4f1 How reproducible: 100% Steps to Reproduce: 1.Add a provider(i had added scvmm) 2.create a catalog item for the above added provider 3.delete the provider 4.order the service Actual results: Error: undefined method `provision_class' for NilClass:Class is thrown.see attached screenshot Expected results: Additional info: evm.log [----] I, [2016-11-17T04:56:45.853210 #11883:3cf140] INFO -- : Q-task_id([service_template_provision_request_7]) MIQ(MiqProvisionRequestTemplate#create_tasks_for_service) create_tasks_for_service ID 5 SCALING : 1 [----] E, [2016-11-17T04:56:45.870128 #11883:3cf140] ERROR -- : Q-task_id([service_template_provision_request_7]) [NoMethodError]: undefined method `provision_class' for NilClass:Class Method:[rescue in create_request_tasks] [----] E, [2016-11-17T04:56:45.870390 #11883:3cf140] ERROR -- : Q-task_id([service_template_provision_request_7]) /var/www/miq/vmdb/app/models/miq_provision_request.rb:34:in `request_task_class_from' /var/www/miq/vmdb/app/models/miq_provision_request.rb:38:in `new_request_task' /var/www/miq/vmdb/app/models/miq_request.rb:436:in `create_request_task' /var/www/miq/vmdb/app/models/miq_provision_request_template.rb:9:in `block in create_tasks_for_service' /var/www/miq/vmdb/app/models/miq_provision_request_template.rb:8:in `times' /var/www/miq/vmdb/app/models/miq_provision_request_template.rb:8:in `each' /var/www/miq/vmdb/app/models/miq_provision_request_template.rb:8:in `collect' /var/www/miq/vmdb/app/models/miq_provision_request_template.rb:8:in `create_tasks_for_service' /var/www/miq/vmdb/app/models/service_template_provision_task.rb:76:in `create_child_tasks' /var/www/miq/vmdb/app/models/service_template_provision_task.rb:68:in `after_request_task_create' /var/www/miq/vmdb/app/models/service_template.rb:224:in `block (2 levels) in create_subtasks' /var/www/miq/vmdb/app/models/service_template.rb:200:in `upto' /var/www/miq/vmdb/app/models/service_template.rb:200:in `each' /var/www/miq/vmdb/app/models/service_template.rb:200:in `block in create_subtasks' /opt/rh/cfme-gemset/gems/activerecord-5.0.0.1/lib/active_record/relation/delegation.rb:38:in `each' /opt/rh/cfme-gemset/gems/activerecord-5.0.0.1/lib/active_record/relation/delegation.rb:38:in `each' /var/www/miq/vmdb/app/models/service_template.rb:198:in `create_subtasks' /var/www/miq/vmdb/app/models/service_template.rb:192:in `create_tasks_for_service' /var/www/miq/vmdb/app/models/service_template_provision_task.rb:76:in `create_child_tasks' /var/www/miq/vmdb/app/models/service_template_provision_task.rb:68:in `after_request_task_create' /var/www/miq/vmdb/app/models/miq_request.rb:442:in `create_request_task' /var/www/miq/vmdb/app/models/miq_request.rb:412:in `block in create_request_tasks' /var/www/miq/vmdb/app/models/miq_request.rb:411:in `each' /var/www/miq/vmdb/app/models/miq_request.rb:411:in `create_request_tasks' /var/www/miq/vmdb/app/models/miq_queue.rb:347:in `block in deliver' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:91:in `block in timeout' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:33:in `block in catch' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:33:in `catch' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:33:in `catch' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:106: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:343: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' /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:341:in `start' /var/www/miq/vmdb/app/models/miq_worker.rb:270:in `start_worker' /var/www/miq/vmdb/app/models/miq_worker.rb:150:in `block in sync_workers' /var/www/miq/vmdb/app/models/miq_worker.rb:150:in `times' /var/www/miq/vmdb/app/models/miq_worker.rb:150: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:158:in `start' /var/www/miq/vmdb/app/models/miq_server.rb:248: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>'
So this was fixed by bug 1210541, verified in 5.7.0.0, but broke again in 5.7.0.11
Dave - I think that is incorrect. The bug 1210541 refers to **editing** a catalog item after ordering which should still work. This bug is actually ordering the service.
John - We added logic to the backend a while ago to support checking if a service_template was still valid (PR https://github.com/ManageIQ/manageiq/pull/3247). This likely needs some updating to support some of the newer sub-classed service_template types but the basic logic still holds true. The idea for this logic was to allow the UI to indicate to an Admin if the service_template needed to some type of repair. For example, the template backing a provision was removed or some other resource is no longer valid. This logic could also be used to prevent ordering of a broken Catalog Item. PM: 1) What is the expected UI behavior for ordering? Should the item be hidden from the user? Or should the item be visible but marked as broken (Would alleviate trying to figure out why a service is not visible.) 2) There is need for UX design work here as there are two audiences: Admin and User. (These changes would impact both OpsUI and SUI)
I'm afraid I'm not sure. I think we'll need Ladas or Greg B to chime in.
Uploading the VHDs is certainly a step. Did you tell Azure to make them images? https://mojo.redhat.com/people/dlamotta/blog/2016/08/08/azure-image-preparation-for-cloudforms-use Also, when you create the catalog item using the template we ship, did you make sure to select Catalog Item Type = Orchestration and not Catalog Item Type = Azure. The video above chooses azure and that will not work.
I'm not sure what else to add other than to say that if the uploaded images do not have the expected properties that we look for, then they will not show up. Otherwise they will show up, assuming they're on a storage account located within your CFME provider's region. Managed images should be working fine since those PR's were merged and backported.
Managed Images are supported in 5.7.3 and 5.8.1 The orchestration example template we ship does not support Managed Images. Since all the customer tickets are closed, I'm going to move this to verified.