Bug 1695804

Could I please get this retested on a later 5.10 version?

I believe this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1667947
which is waiting for a hammer back port.

i could not retest on the newer 5.10.2 as I faced another bug 1700540

has anything changed in the code that would affect the behavior of this issue?

@Tina the bug 1667947 is related to the Classic UI, this is the same issue but on the Self Service UI which uses different pages and it affects all user activities on that service.

i did retest it with 5.10.2.2-1 using dynamic drop down instead of the dynamic text box which has the bug 1700540 and CloudForms is still running the code every time I open the service from the self_service interface.

I don't think that this is a dup of the one in comment 3, actually. But it'd be cool to get a UI person to look at this.

Steps to reproduce - setup:


1. in Ops UI, create a slow automate method & instance

  go to Automation > Automate > Explorer
  add a new method anywhere, type: inline, method body:

    sleep 20 # wait 20 seconds
    $evm.root['default_value'] = Time.now.to_s
    exit MIQ_OK

  add a new instance in the same place, value = name of the new method


2. in Ops UI, create a dialog, with a dynamic field backed by the slow method

  go to Automation > Automate > Customization
  accordion Service Dialogs
  toolbar Configuration > Add a New Dialog

  add a textbox, edit detail
  tab Field Information
    enable Dynamic
  tab Options
   set entry point to the newly created instance


3. in Ops UI, create a catalog item using the dialog

  go to Service > Catalogs > Catalog Items

  add a new catalog item,
  type Generic,
  select the newly created Dialog,
  enable Display in Catalog,
  select a Catalog


4. in Ops UI, order the catalog item

  go to Service > Catalogs > Service Catalogs
  order the new catalog item,
  (loading the dialog will wait the 20 seconds specified in the method)

  the UI redirects to a list of requests, click the new request,
  approve it (seems to happens by itself when the queue worker is running)


5. in Ops UI, make sure the new service was created,

  go to Service > My Services
  look for the new service (if "bz1695804" was the name of the catalog item, the service gets a name like "bz1695804-20190626-152519")

Steps to reproduce - Service UI:

1. open Service UI, go to My Services
2. open the newly provisioned service detail screen (url like /services/184)


Actual results:

service takes 20 seconds to open,
manageiq/log/automation.log contains info about the automate method getting instantiated and invoked during that time


Expected results:

all the values of the service should be loaded directly from the database,
no 20 second wait should happen,
no new entries in automation.log


Additional info:

The UI queries the API for the field data, that request takes 20 seconds, and gets repeated periodically when the service detail screen is open:

GET /api/services/184?attributes=name%2Cguid%2Ccreated_at%2Ctype%2Cdescription%2Cpicture%2Cpicture.image_href%2Cevm_owner.name%2Cevm_owner.userid%2Cmiq_group.description%2Caggregate_all_vm_memory%2Caggregate_all_vm_disk_count%2Caggregate_all_vm_disk_space_allocated%2Caggregate_all_vm_disk_space_used%2Caggregate_all_vm_memory_on_disk%2Cretired%2Cretirement_state%2Cretirement_warn%2Cretires_on%2Cactions%2Ccustom_actions%2Cprovision_dialog%2Cservice_resources%2Cchargeback_report%2Cservice_template%2Cparent_service%2Cpower_state%2Cpower_status%2Coptions%2Cvms.ipaddresses%2Cvms.snapshots%2Cvms.v_total_snapshots%2Cvms.v_snapshot_newest_name%2Cvms.v_snapshot_newest_timestamp%2Cvms.max_mem_usage_absolute_average_avg_over_time_period%2Cvms.hardware%2Cvms.hardware.aggregate_cpu_speed%2Cvms.cpu_usagemhz_rate_average_avg_over_time_period%2Cgeneric_objects.picture%2Cgeneric_objects.generic_object_definition%2Cvms.supported_consoles&expand=vms%2Corchestration_stacks%2Cgeneric_objects

https://github.com/ManageIQ/manageiq-ui-service/pull/1551

New commits detected on ManageIQ/manageiq-ui-service/master:

https://github.com/ManageIQ/manageiq-ui-self_service/commit/6df0bea68910a689a9a958fc57703d4dce28ca48
commit 6df0bea68910a689a9a958fc57703d4dce28ca48
Author:     Martin Hradil <mhradil>
AuthorDate: Fri Jun 28 07:30:49 2019 -0400
Commit:     Martin Hradil <mhradil>
CommitDate: Fri Jun 28 07:30:49 2019 -0400

    Services.getService - add runAutomate parameter, defaults to true

    Asking the API for `provision_dialog` evaluates any automate methods it needs to populate the dialog data.
    That's not always desirable, parametrizing.

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

 client/app/services/services-state.service.js | 6 +-
 client/app/services/services-state.service.spec.js | 2 +-
 docs/howto.md | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)


https://github.com/ManageIQ/manageiq-ui-self_service/commit/1466c421ea4d9ddc35927024392ff5e7ff6d345d
commit 1466c421ea4d9ddc35927024392ff5e7ff6d345d
Author:     Martin Hradil <mhradil>
AuthorDate: Fri Jun 28 08:14:15 2019 -0400
Commit:     Martin Hradil <mhradil>
CommitDate: Fri Jun 28 08:14:15 2019 -0400

    Service detail - don't run automate when displaying service detail screen

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

 client/app/services/service-details/service-details.component.js | 2 +
 1 file changed, 2 insertions(+)