Created attachment 610084 [details] test manifest Description of problem: Version-Release number of selected component (if applicable): Katello Version: 1.1.9-1.git.130.edb680c.el6_3 How reproducible: always Steps to Reproduce: 1. Create new org, switch to it 2. Go to upload attached manifest to the org, enter repo url https://asdf.com 3. Select the manifest file and upload it 4. Fails with Connection timed out 5. Now try again use the correct repo url for the manifest http://inecas.fedorapeople.org/fakerepos/cds/ 6. Upload the same manifest file again Actual results: Subscription manifest upload for provider 'Red Hat' failed. Reason: Import is older than existing data Resources::Candlepin::Owner: 409 Conflict {"displayMessage":"Import is older than existing data"} (POST /candlepin/owners/asdfasdf/imports) (RestClient::Conflict) {"displayMessage":"Import is older than existing data"} Expected results: Upload completes successfully 2nd time Additional info: Appears to be a problem where the content is not checked BEFORE importing into candlepin. Or at the very least done in a transactional way that can be rolled back.
There is a cli command `provider refresh_products` that does is able to re-create missing repositories based on the CDN. We need to import the manifest to Candlepin to get the urls and certificates. Therefore we can't do the check before that. Unfortunately, AFAIK Candlepin doesn't support roll-backing the manifest import.
After investigation and discussion with Devan (candlepin) and Ivan (katello), it seems that we'll need some modifications to candlepin to address this bugzilla. Today, we do not have a way from katello to determine whether or not a manifest has already been imported. Given that candlepin processes the manifest, it is probably the best place to determine whether or not it has been previously imported, returning a response such as 'this manifest has already been imported'. Using that response, katello can use the refresh_products suggested by Ivan above to handle the creation of the repositories in katello. The issue raised has been added to the candlepin backlog.
katello pull request: https://github.com/Katello/katello/pull/626 katello commit: https://github.com/Katello/katello/commit/694c1ed90bc77d94fa850baa9a0555c039a9e936 The above commit contains changes such that if a user attempts to import a manifest (when a previous import has not been successfully completed) and the import fails, the orchestration will rollback (i.e. unimport) the manifest. This change is to address a scenario like the following: - user sets the CDN to an invalid value - user imports a manifest - the import of the manifest in to candlepin succeeds; however, the creation of the repos using candlepin/cdn fails (since the cdn url is bad) With this change, the user can fix the cdn url and attempt a reimport.
Tried to follow the same exact steps mentioned in the issue. The first 2 times I tried to import the manifest file with the correct CDN value, I received a message stating "Owner has already imported from another distributor". Today I tried to import it again, but using the http://asdf.com CDN and now I got: Subscription manifest upload for provider 'Red Hat' failed. Reason: Import is older than existing data Resources::Candlepin::Owner: 409 Conflict {"displayMessage":"Import is older than existing data"} (POST /candlepin/owners/AlphabetSoup/imports) (RestClient::Conflict) {"displayMessage":"Import is older than existing data"}
Ok, so this issue can be verified if I follow the steps to the "T", but if you try to import the manifest using an incorrect CDN url more than once before using the correct url, then you hit the error mentioned in comment #c8
The changes introduced 'delete' the manifest from candlepin, if the total successful imports is 1 (i.e. this is the first import attempt). Since katello does not currently store the import history locally, the 'total' is determiend by looking at the candlepin history. The issue we are encountering is essentially the following: - user sets CDN to invalid value - user attempts to import a manifest - the import of the manifest to candlepin succeeds (history total=1) - the creation of repos fails - katello deletes the manifest from candlepin (i.e. total == 1) - user attempts to import a manifest (again) - the import of the manifest to to candlepin succeeds (history total=2) - the creation of repos fails - katello does not delete manifest from candlepin (i.e. total > 1) - user attempts to import a manifest (again) - the import of the manifest to candlepin fails... reason being, it could not be deleted on the previous failure, so candlepin reports that this import is 'older than existing data' Unfortunately, katello does not currently have a way with current data to determine on that second failed attempt to delete the manifest. It is quite possible that first success was a true success, systems were registered, subscribed and are consuming content. As a result, we cannot simply delete the manifest again, without affecting existing subscriptions. In order to address this behavior, the following are a couple of things that could potentially help: 1. Update candlepin to destroy the import history for an owner, when a manifest is deleted. Since the manifest is no longer there, not sure that the history is very useful. If this was done, in the above scenario the second failed attempt would again delete the manifest from candlepin. 2. Update candlepin to report to katello that the manifest has already been imported (i.e. rather than report 'older than existing data', report 'already imported'). Using this information, katello could be updated to make a decision to continue with the second phase of the import process, which is to create the repositories. (Note: this is currently on candlepin backlog) There are likely other solutions; however, posing a couple of possibilities.
What Brad said in comment #10 is correct. There isn't a simple way to fix this in the time we have for the current release we are shipping this in. In our upcoming release we will need to make changes in Katello and Candlepin to better address the issue to support better rollbacks of our imports. I filed a 2.0 bug here: https://bugzilla.redhat.com/show_bug.cgi?id=857963 and I'd vote we move this to VERIFIED
Verified using: * candlepin-0.7.8-1.el6cf.noarch * candlepin-selinux-0.7.8-1.el6cf.noarch * candlepin-tomcat6-0.7.8-1.el6cf.noarch * katello-1.1.12-7.el6cf.noarch * katello-all-1.1.12-7.el6cf.noarch * katello-candlepin-cert-key-pair-1.0-1.noarch * katello-certs-tools-1.1.8-1.el6cf.noarch * katello-cli-1.1.8-4.el6cf.noarch * katello-cli-common-1.1.8-4.el6cf.noarch * katello-common-1.1.12-7.el6cf.noarch * katello-configure-1.1.9-3.el6cf.noarch * katello-glue-candlepin-1.1.12-7.el6cf.noarch * katello-glue-pulp-1.1.12-7.el6cf.noarch * katello-qpid-broker-key-pair-1.0-1.noarch * katello-qpid-client-key-pair-1.0-1.noarch * katello-selinux-1.1.1-1.el6cf.noarch * pulp-1.1.12-1.el6cf.noarch * pulp-common-1.1.12-1.el6cf.noarch * pulp-selinux-server-1.1.12-1.el6cf.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-1543.html
getting rid of 6.0.0 version since that doesn't exist