Bug 1613935 - Ordering a service using $evm.execute('create_service_provision_request') doesn't honor the dialog options
Summary: Ordering a service using $evm.execute('create_service_provision_request') doe...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate
Version: 5.9.4
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: GA
: 5.10.0
Assignee: eclarizi
QA Contact: Kedar Kulkarni
URL:
Whiteboard:
Depends On:
Blocks: 1564236 1564250 1608420 1615634
TreeView+ depends on / blocked
 
Reported: 2018-08-08 15:10 UTC by Fabien Dupont
Modified: 2019-02-12 16:52 UTC (History)
11 users (show)

Fixed In Version: 5.10.0.11
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1615634 (view as bug list)
Environment:
Last Closed: 2019-02-12 16:52:19 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Fabien Dupont 2018-08-08 15:10:48 UTC
Description of problem:
When calling $evm.execute('create_service_provision_request',...) the dialog options are not passed to the service provisioning request. It has been observed when calling /System/Request/Order_Ansible_Playbook, which uses 'create_service_provision_request'.

When provisioning the service from the service catalog, the dialog options are correctly passed.

Version-Release number of selected component (if applicable): 5.9.4.2


How reproducible: Always


Steps to Reproduce:
1. Create an Ansible Playbook service template, named 'MyPlaybook', creating a new dialog with 'Create new' button.

2. From rails console:

irb> $evm = MiqAeMethodService::MiqAeService.new(MiqAeEngine::MiqAeWorkspaceRuntime.new)
irb> $evm.execute(:create_automation_request, { :namespace => 'System', :class_name => 'Request', :instance_name => 'Order_Ansible_Playbook', :attrs => { :service_template_name => 'MyPlaybook', :hosts => "192.168.122.32" }, :user_id => 1 }, 'admin', true)


Actual results:
In automation.log, the preprocess method dumps $evm.root attributes and we can see that hosts attribute is equal to localhost, which is the default value.

Expected results:
The hosts attribute is equal to 192.168.122.32.

Additional info:

Comment 10 Fabien Dupont 2018-08-09 10:52:28 UTC
I have done extra tests this morning, to set aside the Ansible aspect.

On my CloudForms 5.9.4.2 appliance, I have created a state machine with a single state that dumps $evm.root attributes. This is convenient to see the dialog options. Then, I have created a dialog with a single field, named 'hosts' and with 'localhost' as default value. Then, I have created a generic service catalog item that calls this state machine on provisioning.

I have created a new request endpoint /System/Request/Order_Service that calls a method named order_service and whose code is:

svc_tpl = $evm.vmdb(:service_template).find_by(:name => 'dump')
dlg_opts = { :hosts => '192.168.122.32' }
$evm.execute('create_service_provision_request', svc_tmp, dlg_opts)

This request endpoint allows me to call $evm.execute('create_automation_request') from rails console to order the service catalog item.

request_hash = {
  :namespace => 'System',
  :class_name => 'Request',
  :instance_name => 'order_service',
  :user_id => 1
}
$evm.execute(:create_automation_request, request_hash, 'admin', true)

I have ordered the service from the service catalog (admin UI), overriding the 'hosts' field with '192.168.122.32'. In automation.log, I see that $evm.root['dialog_hosts'] is equal to '192.168.122.32'.

I have order the service using $evm.execute('create_automation_request'), which calls /System/Request/order_service method, which orders the service with $evm.execute('create_service_provision_request') and overrides 'hosts' with '192.168.122.32'. In automation.log, I see that $evm.root['dialog_hosts'] is equal to 'localhost'.

I have setup the same environment with a CloudForms 5.9.3.4 appliance and run the same tests. With this version, $evm.root['dialog_hosts'] is equal to '192.168.122.32' whatever method I use to order the service. So, it is a regression between 5.9.3.4 and 5.9.4.2.

Comment 13 drew uhlmann 2018-08-10 17:57:52 UTC
https://github.com/ManageIQ/manageiq/pull/17839

Comment 15 CFME Bot 2018-08-13 21:01:50 UTC
New commits detected on ManageIQ/manageiq/master:

https://github.com/ManageIQ/manageiq/commit/4b046292408445b2fe2de986870b7b114a8c160d
commit 4b046292408445b2fe2de986870b7b114a8c160d
Author:     Erik Clarizio <eclarizi>
AuthorDate: Fri Aug 10 17:39:11 2018 -0400
Commit:     Erik Clarizio <eclarizi>
CommitDate: Fri Aug 10 17:39:11 2018 -0400

    Add specific funnel for provision_workflow

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1613935

 app/models/dialog.rb | 2 +
 app/models/resource_action_workflow.rb | 3 +
 app/models/service_template.rb | 15 +-
 spec/models/dialog_spec.rb | 23 +
 spec/models/resource_action_workflow_spec.rb | 10 +
 spec/models/service_template_spec.rb | 34 +-
 6 files changed, 77 insertions(+), 10 deletions(-)


https://github.com/ManageIQ/manageiq/commit/f15c18b8a8b81c57fb64d071426c6b0980a650fa
commit f15c18b8a8b81c57fb64d071426c6b0980a650fa
Author:     Erik Clarizio <eclarizi>
AuthorDate: Mon Aug 13 11:00:10 2018 -0400
Commit:     Erik Clarizio <eclarizi>
CommitDate: Mon Aug 13 11:00:10 2018 -0400

    Allow nil values to not overwrite old values in #load_values_into_fields

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1613935

 app/models/dialog.rb | 7 +-
 app/models/resource_action_workflow.rb | 2 +-
 app/models/service_template.rb | 2 +-
 spec/models/dialog_spec.rb | 33 +
 spec/models/resource_action_workflow_spec.rb | 2 +-
 5 files changed, 41 insertions(+), 5 deletions(-)

Comment 17 Kedar Kulkarni 2018-08-23 17:39:40 UTC
With CFME build 5.10.0.11 I was able to execute the Pre-migration playbooks against the correct IP address of my VM being migrated. So seems like the issue is resolved.


Note You need to log in before you can comment on or make changes to this bug.