Bug 538144
| Summary: | Deleting a synced repository removes the channel from the available channel list from content source | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | wes hayutin <whayutin> | ||||||||
| Component: | Content | Assignee: | Jay Dobies <jason.dobies> | ||||||||
| Status: | CLOSED WORKSFORME | QA Contact: | wes hayutin <whayutin> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | urgent | ||||||||||
| Version: | unspecified | CC: | cwelton, jason.dobies | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| URL: | http://core-01.usersys.redhat.com:7080/rhq/content/importRepos.xhtml?conversationId=3272 | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2010-03-26 12:37:07 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 538145 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
wes hayutin
2009-11-17 18:28:45 UTC
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. |