Description of problem: Deleting a synced repository removes the channel from the available channel list from content source. Steps to reproduce 1. go to http://core-01.usersys.redhat.com:7080/rhq/content/listRepos.xhtml Content -> providers 2. click import - import a repository, ie.. redhat-linux-alpha-6.2 - rhq successfully imports the channel "1 Repositories imported from Content Provider" 3. Delete the freshly imported repository, redhat-linux-alpha-6.2 repository is successfully deleted, although there is not message 4. try to re-import the repository , redhat-linux-alpha-6.2 The repository is no longer available to be imported. It does not show up in the list
Created attachment 369930 [details] import a repo
Created attachment 369931 [details] delete a repo
Created attachment 369932 [details] repo is missing from the hosted list
I'm not able to reproduce this, but I suspect it's due to a lack of documentation on how the candidate repos are supposed to work. Candidate repos are introduced into the system when a content provider is syncced. In other words, I have a RHN hosted provider that periodically asks hosted what repos it can introduce into the system. For any repos that aren't already imported, it adds a candidate repo that is shown in the import list. When a repo is imported, it's yanked out of the candidate queue and made a real (imported) repo. In the database, that just flips a flag, using the same entry in the repo table. When a repo is deleted, that row is then deleted from the database. It's not reconfigured to be an imported repo again. However, when the next hosted provider sync takes place, that repo will be part of the sync and be re-created in the database as a candidate repo. At that point, you'll be able to reimport it again (technically speaking, there is nothing "re-import" about it, it's effectively as if the initial import hadn't taken place). All that said, I think this is the functionality we want. I'm hesitant to get into the process of tracking which repos were the results of an import and thus flipping them back into the candidate repo queue on a delete. There's a lot If anything, I'd say we could schedule an immediate provider sync for all providers associated with a repo when it is deleted. That would cause that repo to reappear in the candidate list. Although I think we'd be safe to just leave this as a documentation point.
>If anything, I'd say we could schedule an immediate provider sync for all >providers associated with a repo when it is deleted. That would cause that repo >to reappear in the candidate list. Although I think we'd be safe to just leave >this as a documentation point. I like the idea of doing a provider sync, though if we just want to document the current behaviour, I'm amenable.
QA Closing.