Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 586027 - Wrong InfoBlock message when sync selected Repositories with no content.
Wrong InfoBlock message when sync selected Repositories with no content.
Status: CLOSED NOTABUG
Product: RHQ Project
Classification: Other
Component: Content (Show other bugs)
1.4
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: Simeon Pinder
Corey Welton
:
Depends On:
Blocks: jon24-content
  Show dependency treegraph
 
Reported: 2010-04-26 12:28 EDT by John Sefler
Modified: 2010-05-21 11:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-21 11:46:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Sefler 2010-04-26 12:28:26 EDT
Description of problem:
During this IManage/JON24 development cycle, Content Sources were renamed to Content Providers and later reverted back.  During the revert, one of the corrected behaviors was lost in the revert.  Please bring it back, its blocking an automated test....
When selecting repositories to sync that actually contain no content, the InfoBlock message used to correctly say "Selected Repositories have no content to sync." and now it incorrectly states "Synchronizing [1] content sources." when the selected repository actually has no content.


Version-Release number of selected component (if applicable):
 RHQ
version: 3.0.0-SNAPSHOT
build number: 4fd30d0 

How reproducible:


Steps to Reproduce:
1. Create a new Repository...   Administration > Content > Repositories
2. check the new repository and click SYNC SELECTED
  
Actual results:
Synchronizing [1] content sources. 

Expected results:
Selected Repositories have no content to sync.
Comment 1 Simeon Pinder 2010-05-05 16:23:49 EDT
This is not just a matter of adding the message information back.  Due to the code changes that have been made, the method no longer has access to real time data about whether the N synchronized messages actually had any content to display.  It looks like the previous synchronous nature was causing delays in the UI under load. 

The mechanism was changed to be asynchronous in nature so that complete synchronization occurs in a scheduled operation.

The short of it is that the we no longer provide that type(completed and how) of messaging in the top level 'Content Sources' synchronize gui action to the client.  

How is the test being blocked by no longer having this information? 

You should still be able to get this information by browsing the "Synchronization Results History" for the specific Content Source that the synchronization was being run on.  You will likely need to monitor the status to of the most recent Synchronization run for "Successful" or "IN PROGRESS" and then view the results.  That part could probably be achieved by a CLI script.

One more note: viewing the results of a synchronization is affected by BZ 589199.
Comment 2 John Sefler 2010-05-06 10:16:38 EDT
 RHQ
version: 3.0.0-SNAPSHOT
build number: b338c7f 

When a Repository has NO associated content source and it is selected for synchronization.  The resulting Synchronization Status is SUCCESS and the Synchronization Results are:

Thu May 06 09:54:32 EDT 2010: Start synchronization of Repository [foo]
Thu May 06 09:54:32 EDT 2010: Getting currently known list of content source packages...

Thu May 06 09:54:32 EDT 2010: Repository [foo] completed syncing with no errors.


I would have expected the results to say something to the effect that "Selected Repositories have no content to sync." as it used to say in an earlier version of IManage.
Comment 3 Simeon Pinder 2010-05-10 12:05:32 EDT
Before we would i) launch the synchronization and ii)the wait for the results in the UI thread before iii) displaying those results back.  

Since we've moved steps ii and iii into it's own thread, then the only information we can offer back to the user immediately is that N synchronization requests have been started and whether there was a problem trying to schedule them.  Meaning that regardless of results for each content source, the operation was requested/initialized successfully.  

It's usually a good practice to not include potentially process intensive operations in the initial user response.  To properly monitor the status of the synchronization request, the user will need to look at the "Synchronization History" for the specific 'Content Source' and monitor the entries appropriately. This pattern is used successfully other places in the RHQ UI.
Comment 4 Corey Welton 2010-05-21 11:46:32 EDT
QA Closing - we can reopen later if necessary.

Note You need to log in before you can comment on or make changes to this bug.