Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: This occurs with any/all dependent dropdown fields in a dialog. Essentially what is happening is (regardless of initialize on load setting) -> if there is a dialog that has a subordinate dialog, the 2nd dialog wont refresh with accurate data. Version-Release number of selected component (if applicable): 5.9.2.4 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hey Ryan, can we please have a reproducing environment to check this issue out?
Hi Ryan, Can you ask the customer to provide the dialog and Automate domain? Thanks, Tina
I don't think the image in 7 is related to this case. The issue I believe we're seeing in that video is a patternfly problem that has nothing to do with the backend, or service dialogs, or for that matter MIQ at all. We're working on validating and coming up with a fix but it's difficult to tell what's happening in that video because it's super-fast.
Hi Ryan, We were not able to reproduce the customer dialog issue. We created 2 Automate methods to replace the customers methods for list_datastore and list_isos. Attached is a TEST domain Erik created. Could you ask the customer to run a test for us where they use the dropdown1 and dropdown2 Automate methods in place of their methods? We need to know if it has something/anything to do with the data. If the dialog fails the same way as when they use their dialogs, I'd like to look into how the upgrade was performed to see if the upgrade has anything to do with the differing behavior. Let me know if you have any questions. Thanks, Tina
Created attachment 1449182 [details] test Automate domain for dropdown dialog test test Automate domain for dropdown dialog test
Hi Tina, The customer tested with the TEST domain and provided the following feedback. Upon using the automate code provided, the direct refresh of the iso files does work as intended. When selecting a datastore, the iso file dropdown is updated with the proper content based on the datastore.
Hi Ryan, Thanks for the update. We're wondering if the upgrade from 5.8 to 5.9 has anything to do with the issue. Could you ask the customer to performa the same test with a new 5.9.2.4 appliance. If the dialogs work as expected, can you ask them to provide detail about the upgrade process? If the dialog does not work properly, can you ask them to use our test Automate methods in place of their Automate methods. We'd like to setup another call with the customer once we get the requested information. Depending on the turn around time, we're available at 4pm EDT today and 11am EDT on Tuesday. Let me know if you have any questions. Thanks, Tina
Hi Ryan, Can you setup the call for 12:30 EDT tomorrow? Can you ask the customer if the upgraded 5.9.2.4 appliance has had any hot fixes applied? If so, are they able to test on an upgraded appliance that does not have the hot fix applied? Thanks, Tina
compare the packages on the working "fresh 5.9" and non-working upgraded 5.9: rpm -qa | sort Look for any differences. We can also see if there are any changes applied to the working and non-working appliances: (my example below shows some changes that are completely unrelated but are provided as an example [root@localhost ~]# rpm -qV `rpm -qa |grep cfme` S.5....T. /var/www/miq/vmdb/productization/appliance_console/locales/appliance/en_productization.yml S.5....T. /var/www/miq/vmdb/productization/appliance_console/locales/container/en_productization.yml S.5....T. /var/www/miq/vmdb/tmp/cache/sti_loader.yml S.5....T. /opt/rh/cfme-gemset/gems/manageiq-appliance_console-2.0.0/locales/appliance/en.yml S.5....T. /opt/rh/cfme-gemset/gems/manageiq-appliance_console-2.0.0/locales/container/en.yml rpm reinstall cfme-gemset will repair the gemset which might fix the es6-shim issue
I did a quick overview of the changes rpms and the only things that stand out to me: The clean install system: kernel-3.10.0-862.el7.x86_64 (and related kernel packages) Upgraded systems: kernel-3.10.0-693.17.1.el7.x86_64 The upgraded systems have lots of additional diagnostic/development packages that should be unrelated but complicates things. Finally, the upgraded systems have old rpms we no longer use: rh-ruby23-rubygem-eventmachine (for thin gem) rh-ruby23-rubygem-thin ... I don't see anything else that stands out.
Hi Ryan, Using your reproducer environment: 10.12.214.41 I've imported the custom Automate domain and the Mount ISO Service Dialog. When I select the order the "TKY VMware Provision from ISO" Service, the Service dialog is displayed with the "Choose Datastore" and "Choose ISO" dialog entries. I know the dynamic methods for those items exist, and yet, I get a script error. I assumed that since we had the customers DB, that would not be an issue. Could you ask the customer to provide specifics as to how to order/setup the Service? I'm signed in as Admin and I can see that the datastores are not tagged...... I get this error: with_scope] with inputs [{}] [----] I, [2018-06-12T16:46:09.244180 #32253:ae0efc] INFO -- : <AEMethod [/Cisco_CALO/Integration/VMware/DynamicDialogs/vmware_list_datastores_with_scope]> Starting [----] I, [2018-06-12T16:46:09.842194 #32253:7d4678] INFO -- : <AEMethod vmware_list_datastores_with_scope> CloudForms Automate Method Started [----] E, [2018-06-12T16:46:09.875496 #32253:bc4f30] ERROR -- : <AEMethod vmware_list_datastores_with_scope> RuntimeError No tags were passed to :any or :all a [----] E, [2018-06-12T16:46:09.876341 #32253:bc4f30] ERROR -- : <AEMethod vmware_list_datastores_with_scope> (druby://127.0.0.1:37550) /var/www/miq/vmdb/lib/extensions/ar_taggable.rb:41:in `find_tagged_with' (druby://127.0.0.1:37550) /opt/rh/cfme-gemset/bundler/gems/cfme-automation_engine-0c3ee3c99138/lib/miq_automation_engine/eng Is there additional setup required to order this Service? Thanks, Tina
Ryan, because there are no obvious rpm changes in the working and non-working environments, we need to look at other things. Are both working (pristine 5.9 appliance) and non-working (upgraded to 5.9) appliances: * in the same region (connecting to the same database) * having similar tools/db_ping.rb times? * having similar ping times from the browser client machine * being accessed from the same browser client (same machine, same browser window (different tab)) * having the same exact dialog screen viewed (same user, order, etc.) * configured with enough memory and cpu to run the same exact UI/web service worker counts (no swap usage, significantly idle in top) * configured with the same number of cfme workers and roles
Hi Ryan, Per our Gitter conversation, could you ask Ron to provide us with a simple service dialog, the automate domain(if we dont already have it) and directions on how to reproduce with the DB they've provided? I agree with you that something is wrong with the database provided. Thanks, Tina
Is it possible for them to deploy a pristine 5.9 in the same location as a "upgraded" one having the problem and point it at the same database? It still seems like a javascript problem but it's hard to compare environments if we're not doing the same "work". So, a pristine 5.9 appliance works on an all-in-one appliance where the browser client is local to the machine and database... (no latency) My guess is that the upgraded 5.9 appliances are slow because of latency and causing delayed async javascript updates. Additionally, I imagine the all-in-one appliance running locally is dedicated to the task of populating the dialogs whereas the upgraded appliances are dealing with latency and other requests since dynamic dialogs run synchronously in UI workers.
Hi Jared, My understanding is that the hot fix we gave the customer resolved the reported issue, but they have another related issue. We've asked that they open a new ticket to track the new issue. The changes in the hot fix will be included in 5.9.3. I'd like to set the status to ON_QA, waiting for the 5.9.3 build. Let me know if you have any questions. Thanks, Tina
Hi Tina , Can you attach the dialog and domain used to recreate this BZ . Or any other steps to be followed to verify this BZ . thanks, Shveta
Hi Shveta, You can use the TEST Automate domain in comment 13. There are service dialogs in the cfme-automate attachment under /exports/ service_dialogs. I'm not sure you'll need to use any of those service dialogs though, because you should be able to create a very simple service dialog with 2 elements. Thanks, Tina
Tina , Please check - https://10.8.196.111 Service - dropdown_bz selecting any value in dropdown 1 shows all values in dropdown 2.
Hi Shveta! I gave the automate code on your appliance the correct names for the fields and if you'll take a second look I think it's working fine.
Created attachment 1455571 [details] Automate domain used for testing
Created attachment 1455572 [details] dialog used for testing Working fine with attached dialog and automate domain . Correct values are loaded . Verified in 5.9.3.3.20180627151410_682cecf