Created attachment 598935 [details] 410 error Description of problem: If you do a subscription-manager unregister, then a katello 'remove system' without a refresh of the screen. You get into a weird state. The UI gets a 410 error from Candlepin then spins. Version-Release number of selected component (if applicable): How reproducible: Hard to tell honestly. But to the best of my knowledge I did a subscription-manager unregister and clicked removed system from the UI (I got impatient) :D Actual results: Katello systems page gets 410, then spins. Expected results: I expect it to get the 410, then remove its record based on the 410 error. Additional info: I also get get: Validation failed: Name has already been taken when I try to migrate the system from RHN Hosted to SystemEngine. (After unregistering, I registered the client with RHN Hosted class) to test out my migration script.
Created attachment 598936 [details] spinning cursor
katello-glue-foreman-0.1.311-1.el6_2.noarch katello-all-0.1.311-1.el6_2.noarch katello-cli-common-0.1.107-1.el6.noarch katello-candlepin-cert-key-pair-1.0-1.noarch katello-qpid-broker-key-pair-1.0-1.noarch katello-glue-pulp-0.1.311-1.el6_2.noarch katello-glue-candlepin-0.1.311-1.el6_2.noarch katello-0.1.311-1.el6_2.noarch katello-configure-0.1.107-1.el6.noarch katello-cli-0.1.107-1.el6.noarch katello-common-0.1.311-1.el6_2.noarch katello-selinux-0.1.10-1.el6.noarch katello-certs-tools-1.0.4-1.el6.noarch katello-qpid-client-key-pair-1.0-1.noarch katello-candlepin-cert-key-pair-1.0-1.noarch katello-glue-candlepin-0.1.311-1.el6_2.noarch candlepin-0.5.26-1.el6.noarch candlepin-tomcat6-0.5.26-1.el6.noarch
Created attachment 598938 [details] error log after clicking systems tab
Leaves katello in unusable state, with the katello db out of sync with the candlepin db. Fencing needs to be in place for handling when 410 come back from candlepin.
This also happens if you delete the consumer from Pulp by hand first. Then attempt to remove it from the UI. Katello will remove the consumer from Candlepin, then error out when it gets a 404 back from Pulp and just stops.
What I would expect is that if a remove system is in process, that Katello handle acceptable error codes from the subsystems: 404 or 410 from Candlepin. 404 from pulp, possibly a 404 from elasticsearch. The logic here is that if we're removing something and it's already gone or not found on the subsystems, then we proceed to make sure we're not in an unable state.
Apparently this happens even with a simple subscription-manager unregister.
Should be fixed by https://bugzilla.redhat.com/show_bug.cgi?id=843462
I have a scenario right now where a 410 is being returned by candlepin and the UI is not happy.
*** Bug 951217 has been marked as a duplicate of this bug. ***
I get a friendly error which says: "Couldn't find System with id=4" I can then refresh the page and it is ok. I am gonna send this to QA.
Verified. Ditto comments as in Comment 13 above. I got a user message in SAM UI - "Couldn't find System with id=84" and refreshing the page after that removed the system. Packages tested: * candlepin-0.8.19-1.el6sam.noarch * candlepin-scl-1-5.el6_4.noarch * candlepin-scl-quartz-2.1.5-5.el6_4.noarch * candlepin-scl-rhino-1.7R3-1.el6_4.noarch * candlepin-scl-runtime-1-5.el6_4.noarch * candlepin-selinux-0.8.19-1.el6sam.noarch * candlepin-tomcat6-0.8.19-1.el6sam.noarch * elasticsearch-0.19.9-8.el6sat.noarch * katello-candlepin-cert-key-pair-1.0-1.noarch * katello-certs-tools-1.4.2-2.el6sat.noarch * katello-cli-1.4.3-5.el6sat.noarch * katello-cli-common-1.4.3-5.el6sat.noarch * katello-common-1.4.3-6.el6sam_splice.noarch * katello-configure-1.4.4-2.el6sat.noarch * katello-glue-candlepin-1.4.3-6.el6sam_splice.noarch * katello-glue-elasticsearch-1.4.3-6.el6sam_splice.noarch * katello-headpin-1.4.3-6.el6sam_splice.noarch * katello-headpin-all-1.4.3-6.el6sam_splice.noarch * katello-selinux-1.4.4-2.el6sat.noarch * thumbslug-0.0.32-1.el6sam.noarch * thumbslug-selinux-0.0.32-1.el6sam.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/RHEA-2013-1390.html