Description of problem: Trying to delete a large repo, I got a timeout error notification on the pulp process. Subsequent attempts to delete repo return a success message, but viewing the Product tree shows the repo as still there. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create a new provider and product 2. Create a new repo for the product called "Fedora - Everything", using the URL "http://download.fedoraproject.org/pub/fedora/linux/releases/15/Everything/x86_64/os/" 3. Sync this repo. 4. After the repo is fully synced, attempt to delete it. Possibly, you should get a fail message. 5. Attempt to delete repo again; observe "green" notification that it has been removed. 6. From the providers view, navigate back down to the Product tree and expand. Actual results: * First, I got the error message: "Pulp::Repository: Request Timeout (DELETE /pulp/api/repositories/ACME_Corporation-f15-x86_64_-_base/)" * subsequently, any attempts to delete show success but the repos are still there. Expected results: Clean deletion Additional info: I'm not sure there's much we can do about the pulp timeout, but we shouldn't be able to be stuck in a half-baked state.
The Pulp team is going to make delete async so our APIs need to be able to handle deletions in this new way.
Repo sync is now asynchronous and returns a task status object with the 202 accepted code. The cli behaviour doesn't track the repo sync like, but instead retains the current behaviour of reporting the repo deleted. Fix pushed in 87f2206e704a54f2c2efbc09cfbb4759ee5d1d8a
mass ON_QA move
I've not had this problem lately, and it's even harder to repro when I'm not seeing the deletion fail in the first place. marking as verified, can reopen later if necessary.
getting rid of 6.0.0 version since that doesn't exist