Description of problem: There are a few operations on objects through Cumin that are processed synchronously rather than asynchronously. For uniformity, and to free up the user after an action is submitted, these operations should be done asynchronously barring any technical or semantic reaons that prevent it. The operations: The Hold, Release, and Remove buttons on the submission summary page Submission of edited values for limits and quotas. Actual results: May be hard to tell in some of these instances (hold, release, remove), but cumin will wait until the operation is completed and then display a yellow task banner with an "OK" message (or failed, if for some reason there was an error). This is easier to see with limit and quota editing, where Cumin displays a "Sending Request" box followed by a yellow task banner with "OK" for the quotas changed. Expected results: If these operations are done asynchronously, operations should be displayed as "Pending" in the task banner and there should be no "Sending Request" notice for quotas and limits. For hold, release, remove it may not always be possible to observe the "Pending" value -- we'll see when the change is made. Currently, those operations seem to happen quickly even when it's synchronous.
Partial fix in revision 4983. Hold, release, and remove have been made asynchronous. Setting values for limits has been made asynchronous. Work on quotas is outstanding.
Quota editing made aynchronous in revision 5088.
Or, as some say, asynchronous (In reply to comment #5) > Quota editing made aynchronous in revision 5088.
How can we test this, please? Is there any testcase for this or just code review?
Well, there are some subtle changes in the behavior on screen from version 2.0 to the changed version that can be observed (as noted in the Description above). The change in behavior for quota editing should be observable. From my perspective, as long as we test and prove that the operations still work I am happy. This was my concern, breaking functionality, otherwise I would have marked it skip-errata. A quick code review (probably a diff) can verify that the code was actually changed. I can post an appropriate diff if you like -- let me know. For Hold, Release, Remove, we probably could inject a delay in the QMF or Aviary response processing as a white box test so that the "Pending" notification is visible in those cases. Would that be useful? However (In reply to comment #7) > How can we test this, please? Is there any testcase for this or just code > review?
Disregard "however", that was a typo/thinking out loud mistake. There is no missing text :) > > However >
Oops, missed this in the svn log. This BZ actually should have gone to MODI with fixed in set to cumin-0.1.5098.
Created attachment 546331 [details] Patch for cumin-0.1.5174 to aid verification of changes This testing patch can be applied in /usr/share/cumin with patch -p1 < bz739658.patch (and undone with patch --reverse -p1 < bz739658.patch) It will add 5 second delays for job remove/hold/release, limit editing, and quota editing. Debug level log messages in web.log will show the delays. This should make it easy to observe the yellow task banners for asynchronous operations in each case. For remove/hold/release, the patch will add the delays for both qmf and aviary since those operations can be done by either. Limit editing and quota editing are only done through QMF. Note, for the aviary calls the delay was added before the call, for qmf the delay was added before the results were returned. This was somewhat arbitrary in the aviary case, but doesn't really matter -- the import bit is that there is adequate time to observe the task banner. Delays can easily be lengthened/shortened by reversing the patch, modifying the patch file, and reapplying.
(In reply to comment #0) > Expected results: > > If these operations are done asynchronously, operations should be displayed as > "Pending" in the task banner and there should be no "Sending Request" notice > for quotas and limits. > > For hold, release, remove it may not always be possible to observe the > "Pending" value -- we'll see when the change is made. Currently, those > operations seem to happen quickly even when it's synchronous. Reproducing old behaviour on MRG 2.0.x from RHN # rpm -q cumin cumin-0.1.4916-1.el5.noarch I was able to see "Pending" when I was doing 'Hold' on job. First 'Hold Job: Pending' and then 'Hold Job: OK' (I was on VPN with slow internet connection.) Is this possible?
Yes. Some of the operations were originally implemented synchronously, some were implemented asynchronously. That particular label ("Hold Job") is on the link from a job details page, and in that case the operation was already asynchronous in 4916. On a slow connection, you might observer it going to "Pending" but generally it is quick enough that a user would just see it go straight to "OK" > > Reproducing old behaviour on MRG 2.0.x from RHN > # rpm -q cumin > cumin-0.1.4916-1.el5.noarch > > I was able to see "Pending" when I was doing 'Hold' on job. > First 'Hold Job: Pending' and then 'Hold Job: OK' > (I was on VPN with slow internet connection.) > > Is this possible?
Reproducing: RHEL5 i386 cumin-0.1.4916-1.el5.noarch (RHN) QMF (package condor-aviary is not installed) -------------------------------------------- The Hold, Release, and Remove buttons on the submission summary page -Grid::Submission::Submit job (aaa, /bin/sleep 3600, true, /tmp) -Grid::Submission::aaa -Wait until job status is "Running" -Select job and click on "Hold" -Wait until job status is "Held" -click on "Release" -Wait until job status is "Running" -click on "Remove" -You should be now in Grid::Submission -Wait until job disappears Submission of edited values for limits - To see limits in cumin, configure according Bug 773378, Comment 0 - Change 'Max Allowance' from '1.0' to: - '0.0' -> "Set Limit: OK", wait until cumin loads new value - '-1.0' -> "The 'Max Allowance' field may not be less than zero." - 'Unlimited' -> "Set Limit: OK", wait until cumin loads new value - 'Sending request' displayed when you try to change value Submission of edited values for quotas - Use configuration example from GUG: Example 10.6. Example configuration for group quotas - restart condor and wait until you see them in cumin - this static quota cannot be changed in cumin - Use configuration example from GUG: Hierarchical Fair Share (HFS) - Try to change values - When flash is off - Bug 773575 - 'Sending request' displayed when you try to change value
Verify: RHEL5 i386/x86_64 cumin-0.1.5184-1.el5.noarch RHEL6 i386/x86_64 cumin-0.1.5184-1.el6.noarch QMF (package condor-aviary is not installed) Bug 773680
Verify: RHEL5 i386/x86_64 cumin-0.1.5184-1.el5.noarch RHEL6 i386/x86_64 cumin-0.1.5184-1.el6.noarch QMF (package condor-aviary is not installed) -------------------------------------------- The Hold, Release, and Remove buttons on the submission summary page - Grid::Submission::Submit job (aaa, /bin/sleep 3600, true, /tmp) - Grid::Submission::aaa - Wait until job status is "Running" - Select job and click on "Hold" - Wait until job status is "Held" - click on "Release" - Wait until job status is "Running" - Bug 773680 - Never seen "Running again" - click on "Remove" - You should be now in Grid::Submission - Wait until job disappears FAILED to verify this part ^^^ (Bug 773680) Submission of edited values for limits - To see limits in cumin, configure according Bug 773378, Comment 0 - Change 'Max Allowance' from '1.0' to: - '0.0' -> "Set Limit: OK", wait until cumin loads new value - '-1.0' -> "The 'Max Allowance' field may not be less than zero." - 'Unlimited' -> "Set Limit: OK", wait until cumin loads new value - 'Sending request' displayed when you try to change value Submission of edited values for quotas - Use configuration example from GUG: Example 10.6. Example configuration for group quotas - restart condor and wait until you see them in cumin - this static quota cannot be changed in cumin - Use configuration example from GUG: Hierarchical Fair Share (HFS) - Try to change values - Bug 760567 - cumin python traceback - When flash is off - Bug 773575 - 'Sending request' displayed when you try to change value FAILED to verify this part ^^^ (Bug 760567)
(In reply to comment #17) > Submission of edited values for limits > - 'Sending request' displayed when you try to change value > > Submission of edited values for quotas > - 'Sending request' displayed when you try to change value 'Sending request' is no more there, instead request is processed asynchronously. -> OK
Verify: RHEL5 i386/x86_64 cumin-0.1.5184-1.el5.noarch RHEL6 i386/x86_64 cumin-0.1.5184-1.el6.noarch The Hold, Release, and Remove buttons on the submission summary page QMF - Bug 773680, comment 6 AVIARY - Bug 773680, comment 7 Submission of edited values for limits (both AVIARY+QMF) - To see limits in cumin, configure according Bug 773378, Comment 0 - Change 'Max Allowance' from '1.0' to: - '0.0' -> "Set Limit: OK", wait until cumin loads new value - '-1.0' -> "The 'Max Allowance' field may not be less than zero." - 'Unlimited' -> "Set Limit: OK", wait until cumin loads new value - 'Sending request' missing - ok (...quotas verification will follow...)
Verify: RHEL5 i386/x86_64 cumin-0.1.5184-1.el5.noarch RHEL6 i386/x86_64 cumin-0.1.5184-1.el6.noarch Submission of edited values for quotas (both AVIARY+QMF) - Use configuration example from GUG: Example 10.6. Example configuration for group quotas - restart condor and wait until you see them in cumin - this static quota cannot be changed in cumin - Use configuration example from GUG: Hierarchical Fair Share (HFS) - Try to change values - in some cases you may expirience problems described in Bug 760567 and in Bug 782359 - When flash is off - Bug 773575 - When flash is on and slow network (I experienced it twice) - Bug 783389 - 'Sending request' missing - ok