Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1694716 - Different syntax by Service Request in Master region
Summary: Different syntax by Service Request in Master region
Keywords:
Status: POST
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate
Version: 5.9.9
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: GA
: 5.11.0
Assignee: Tina Fitzgerald
QA Contact: Niyaz Akhtar Ansari
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks: 1696362 1696363
TreeView+ depends on / blocked
 
Reported: 2019-04-01 13:10 UTC by Gellert Kis
Modified: 2019-04-15 13:01 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1696362 1696363 (view as bug list)
Environment:
Last Closed:
Category: Bug
Cloudforms Team: ---
Target Upstream Version:


Attachments (Terms of Use)

Comment 3 Joe Rafaniello 2019-04-01 14:21:07 UTC
I'm not sure if this requires a code change in automate but being dependent on the type, string or symbol, of hash keys will cause this problem.  We should change any access of these hashes to indifferent access to avoid this problem.  Hashes provided to user scripts should also return these indifferent access hashes to prevent this.

Similar to bug #1654999 and the fix here:  https://github.com/ManageIQ/manageiq/pull/18373

Anything that could go through the rest API, such as master region work, needs to use indifferent access in any options hashes that might be created through the API.  

The API became more strict about deep symbolizing keys here: https://github.com/ManageIQ/manageiq-api/pull/312

The API only gets json payloads so it doesn't know the type, string or symbol, so it was decided to try to make them symbols across the board.
Anything that could consume objects created by the rest API needs to use indifferent access or create objects with methods instead of using options hashes.

Comment 4 vasek 2019-04-02 06:35:44 UTC
In case of backwards compatibility we should use string instead of symbols by request created from master region. This issue is not affecting requests created by API, but also with using of UI

Comment 7 Tina Fitzgerald 2019-04-02 17:33:41 UTC
We're investigating the issue and looking through the customer supplied logs.

Comment 8 Tina Fitzgerald 2019-04-02 19:14:09 UTC
Hi Ryan,

There is a known discrepancy in the dialog parameter keys when ordering a service from the master and local regions.
We did notice this discrepancy in the supplied logs.  We have a fix to a similar issue mentioned in the case, but that was specifically for Orchestration Services.

The customer supplied logs don't show any errors related to service provision.

Can you ask the customer:
1. What type of services they are provisioning?
2. Are they experiencing any errors provisioning the service from the master region?
   If so,
      What is the error message?
      Can they provide detail and logs showing the error?

   If not,
      Is the discrepancy affecting the service provision?
         If so, can they provide detail and logs?

Let me know if you have any questions.

Thanks,
Tina

Comment 9 vasek 2019-04-02 21:42:00 UTC
Hi, I reported that issue to RedHat. That's related to ordering a Service through Service Catalog Item. It's `Item Type`=>`Generic`, `Subtype`=>`Custom`, other values are default. In case of service is ordered through master region you can see in logs dialog parameters as symbols:

[----] I, [2019-04-01T15:24:39.352364 #4866:b5a694]  INFO -- : Q-task_id([service_template_provision_task_50000000029285])  dialog_options: {:dialog_text_box_1=>"ahoj123", :dialog_textarea_box_1=>"ahoj456", "request"=>"clone_to_service", :service_action=>"Provision", "Service::Service"=>50000000000621}

In case you order same service via specific region, there are dialog parameter keys defined as string

[----] I, [2019-04-01T15:26:51.633173 #12684:b5a270]  INFO -- : Q-task_id([service_template_provision_task_50000000029286])  dialog_options: {"dialog_text_box_1"=>"ahoj789", "dialog_textarea_box_1"=>"ahoj012", "request"=>"clone_to_service", :service_action=>"Provision", "Service::Service"=>50000000000622}

Comment 10 vasek 2019-04-02 21:42:25 UTC
Hi, I reported that issue to RedHat. That's related to ordering a Service through Service Catalog Item. It's `Item Type`=>`Generic`, `Subtype`=>`Custom`, other values are default. In case of service is ordered through master region you can see in logs dialog parameters as symbols:

[----] I, [2019-04-01T15:24:39.352364 #4866:b5a694]  INFO -- : Q-task_id([service_template_provision_task_50000000029285])  dialog_options: {:dialog_text_box_1=>"ahoj123", :dialog_textarea_box_1=>"ahoj456", "request"=>"clone_to_service", :service_action=>"Provision", "Service::Service"=>50000000000621}

In case you order same service via specific region, there are dialog parameter keys defined as string

[----] I, [2019-04-01T15:26:51.633173 #12684:b5a270]  INFO -- : Q-task_id([service_template_provision_task_50000000029286])  dialog_options: {"dialog_text_box_1"=>"ahoj789", "dialog_textarea_box_1"=>"ahoj012", "request"=>"clone_to_service", :service_action=>"Provision", "Service::Service"=>50000000000622}

Comment 17 Tina Fitzgerald 2019-04-03 19:38:07 UTC
Hi Ryan,

We're currently validating a potential fix, and will send an update once validated.

Thanks,
Tina

Comment 20 CFME Bot 2019-04-04 13:43:34 UTC
New commit detected on ManageIQ/manageiq-api/master:

https://github.com/ManageIQ/manageiq-api/commit/b550694b77182756593e5c5c5d8796682f792290
commit b550694b77182756593e5c5c5d8796682f792290
Author:     Gregg Tanzillo <gtanzill@redhat.com>
AuthorDate: Wed Apr  3 15:38:00 2019 -0400
Commit:     Gregg Tanzillo <gtanzill@redhat.com>
CommitDate: Wed Apr  3 15:38:00 2019 -0400

    Added logic to support both string and symbol access to keys in dialog hash under options

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

 lib/services/api/request_parser.rb | 6 +-
 spec/lib/services/api/request_parser_spec.rb | 8 +
 2 files changed, 13 insertions(+), 1 deletion(-)

Comment 22 Tina Fitzgerald 2019-04-04 14:41:21 UTC
Hi Brenda,

The code change has been merged, so the development work is complete. 

Regards,
Tina


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