Bug 1694716

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.

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

We're investigating the issue and looking through the customer supplied logs.

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

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}

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}

Hi Ryan,

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

Thanks,
Tina

https://github.com/ManageIQ/manageiq-api/pull/572

New commit detected on ManageIQ/manageiq-api/master:

https://github.com/ManageIQ/manageiq-api/commit/b550694b77182756593e5c5c5d8796682f792290
commit b550694b77182756593e5c5c5d8796682f792290
Author:     Gregg Tanzillo <gtanzill>
AuthorDate: Wed Apr  3 15:38:00 2019 -0400
Commit:     Gregg Tanzillo <gtanzill>
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(-)

Hi Brenda,

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

Regards,
Tina

Verified in Version 5.11.0.4.20190514210444_0c91ee1