Bug 1598475
Summary: | refresh methods stop being called after working for several days in the self service version of dialogs | |||
---|---|---|---|---|
Product: | Red Hat CloudForms Management Engine | Reporter: | Felix Dewaleyne <fdewaley> | |
Component: | Automate | Assignee: | eclarizi | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Shveta <sshveta> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 5.9.0 | CC: | ahoness, cpelland, eclarizi, fdewaley, hkataria, lavenel, mfeifer, mkanoor, mpovolny, obarenbo, simaishi, smallamp, sshveta, tfitzger | |
Target Milestone: | GA | Keywords: | TestOnly, ZStream | |
Target Release: | 5.10.0 | |||
Hardware: | All | |||
OS: | All | |||
Whiteboard: | ||||
Fixed In Version: | 5.10.0.5 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1600738 (view as bug list) | Environment: | ||
Last Closed: | 2019-02-11 14:10:10 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | CFME Core | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1600738 |
Description
Felix Dewaleyne
2018-07-05 15:17:27 UTC
Hi Felix, My understanding is that the customer has dialogs that work for some period of time, then stop working without any changes to the environment. At that point, copying the dialog to a new dialog will result in the correct behavior. Could you ask the customer to send us an example of a "broken" dialog and the copied version that works properly? Could you also ask them to supply the Automate domain(s) needed for the dialog? Let me know if you have any questions. Thanks, Tina Hi Felix, Could you ask the customer to first try restarting the UI appliance when the dialog stops working to see if that resolves the issue? Thanks, Tina (In reply to Tina Fitzgerald from comment #6) > Hi Felix, > > Could you ask the customer to first try restarting the UI appliance when the > dialog stops working to see if that resolves the issue? > > Thanks, > Tina they do that as part of their workarounds. I didn't mention it because I didn't think it really had an impact at all. the workaround of cloning the dialog stopped working today for one dialog. as a note, this only happens in the self service version of the dialog, not the classic ui version. Hi Felix, Thanks for the update. When the customer restarted the UI appliance, did the problem go away? I'm going to check out the new information/logs. A customer call sounds like a good idea, but Erik and I discussed giving the customer some debugging instructions that will give us a better idea of the exact issue. I hope to have specifics shortly. What time(s) would the customer be available today? Thanks, Tina the customer us not available today but is available monday. the customer has tried restarting the appliance to no avail. he loads the dialogs and tails the automation logs at the same time - but the automation isn't at all triggered and no automation call is logged when that happens. I think a remote session would be best to investigate. Are there any javascript errors that are happening? To check, if the customer is using chrome, they can open the developer tools by going to the "..." menu in the upper right, then going to "More tools" and then "Developer tools" before loading the dialog. There should be a console output and when they click around in the dialog, if a javascript error happens, it should be noticeable. If there is no console output, ensure that the "console" tab is selected before loading the dialog and then retry. If the customer is using firefox, they can simply hit F12 to open the developer tools, or they can go to the similar "..." menu and click "developer" and then "toggle tools". However, by default, I don't think Firefox shows the console, so they will then need to click on the little console icon, which is third from the left in the row of icons at the top. Hi Shveta, Could you setup a reproducer environment? Thanks, Tina Hi Felix, I reviewed the recorded session and have a few questions. The customer showed us 2 different environments: cf.cdvu.es.onpremise <----- Everything worked properly here cf.es.onpremise <----- Service UI, Dialog issue reproduced here(7:22 in recording) Linux RHEL con PHP <----- Service Dialog issue Can you ask the customer: 1. Take a screen shot of the "About" version on both appliances. 2. Provide a hot fix version from both appliances (rpm -q cfme-gemset) 3. Supply Service dialogs for Linux RHEL con PHP, from both appliances. Thanks, Tina Hi Felix, Thanks for the update. We haven't been able to reproduce the customer issue. Could you ask the customer to supply the database from the cf.es.onpremise environment? Thanks, Tina Hi Ania, We were able to reproduce the issue using the database provided by the customer. We found the issue and are working on a fix. It's a small change, and we expect to have a PR ready later today. Regards, Tina New commit detected on ManageIQ/manageiq-ui-service/master: https://github.com/ManageIQ/manageiq-ui-self_service/commit/119bd0fd4bf8ecd56470b3a3f932a77e2a78bc9c commit 119bd0fd4bf8ecd56470b3a3f932a77e2a78bc9c Author: Erik Clarizio <eclarizi> AuthorDate: Thu Jul 12 12:57:01 2018 -0400 Commit: Erik Clarizio <eclarizi> CommitDate: Thu Jul 12 12:57:01 2018 -0400 Ensure the provision resource action id is used Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1598475 client/app/states/catalogs/details/details.state.js | 5 +- client/app/states/catalogs/details/details.state.spec.js | 58 +- 2 files changed, 43 insertions(+), 20 deletions(-) Hi Tina , I am not able to verify this BZ on 5.10 . After restoring db and restarting EVM server , the server never starts and I can't login . Please check appliance 10.8.59.85. I also have a new appliance : 10.8.197.235. where I have copied the db but not restored as I can't restart the server once shut down. Thanks, Shveta Hi Shveta, Erik is going to look into this. Thanks, Tina I went in and manually created a test dialog/test catalog item. The reason this bug exists is because when a service template has both a 'Provision' resource action and a 'Retirement' resource action, if the 'Retirement' resource action is for some reason first in the database, it was not using the right resource action ID. So, I've manually changed the "Test" service catalog to emulate what the customer's database was meant to show. irb(main):009:0> ServiceTemplate.last.resource_actions => #<ActiveRecord::Associations::CollectionProxy [#<ResourceAction id: 25, action: "Provision", dialog_id: 2, resource_id: 1, resource_type: "ServiceTemplate", created_at: "2018-08-23 22:20:15", updated_at: "2018-08-23 22:20:15", ae_namespace: "Service/Provisioning/StateMachines", ae_class: "ServiceProvision_Template", ae_instance: "CatalogItemInitialization", ae_message: nil, ae_attributes: {:service_action=>"Provision"}, configuration_template_id: nil, configuration_template_type: nil>, #<ResourceAction id: 26, action: "Retirement", dialog_id: 2, resource_id: 1, resource_type: "ServiceTemplate", created_at: "2018-08-23 22:20:15", updated_at: "2018-08-23 22:20:15", ae_namespace: "Service/Retirement/StateMachines", ae_class: "ServiceRetirement", ae_instance: "Default", ae_message: nil, ae_attributes: {:service_action=>"Retirement"}, configuration_template_id: nil, configuration_template_type: nil>]> I realize this might be hard to follow, but the important bit is that "Provision" is first, and "Retirement" is second. This is the correct scenario and will work even without the fix to this bug. I needed to change this, so I simply updated the ID on the "Provision" dialog to be 27 instead of 25: irb(main):014:0> ResourceAction.where(id: 25).update_all(id: 27) irb(main):016:0> ServiceTemplate.last.resource_actions.first => #<ResourceAction id: 26, action: "Retirement", dialog_id: 2, resource_id: 1, resource_type: "ServiceTemplate", created_at: "2018-08-23 22:20:15", updated_at: "2018-08-23 22:20:15", ae_namespace: "Service/Retirement/StateMachines", ae_class: "ServiceRetirement", ae_instance: "Default", ae_message: nil, ae_attributes: {:service_action=>"Retirement"}, configuration_template_id: nil, configuration_template_type: nil> irb(main):017:0> ServiceTemplate.last.resource_actions.second => #<ResourceAction id: 27, action: "Provision", dialog_id: 2, resource_id: 1, resource_type: "ServiceTemplate", created_at: "2018-08-23 22:20:15", updated_at: "2018-08-23 22:20:15", ae_namespace: "Service/Provisioning/StateMachines", ae_class: "ServiceProvision_Template", ae_instance: "CatalogItemInitialization", ae_message: nil, ae_attributes: {:service_action=>"Provision"}, configuration_template_id: nil, configuration_template_type: nil> Now, you can go into the service UI, and verify that a) it doesn't blow up, and b) if you look at the request made in the developer tools when clicking on the check box I set up, it correctly sends the resource_action_id of '27'. Let me know if you need any other assistance with this, I realize we're not actually using the customer's data here, but I tried to mimic the root cause of the problem with regards to how the backend resource_actions were set up. Hi Shveta, I'm confident this issue has been resolved based on Erik's comments above. Let me know if you have any questions or concerns. Thanks, Tina Checked the dialog mentioned above , dialog doesn't blow up and API log shows ============ [----] I, [2018-08-24T10:44:40.205259 #12140:17351bc] INFO -- : MIQ(Api::ServiceDialogsController.log_request) Parameters: {"action"=>"update", "controller"=>"api/service_dialogs", "format"=>"json", "body"=>{"action"=>"refresh_dialog_fields", "resource"=>{"dialog_fields"=>{"check_box_1"=>"t", "text_box_1"=>"Box is not checked"}, "fields"=>["text_box_1"], "resource_action_id"=>"27", "target_id"=>"1", "target_type"=>"service_template"}}} Verifying based on above comments and testing. |