Bug 847858

Summary:	Blind Rescue causes Activation Key Pools to be Removed when an Exception is thrown
Product:	Red Hat Satellite	Reporter:	Eric Helms <ehelms>
Component:	Content Management	Assignee:	Tom McKay <tomckay>
Status:	CLOSED ERRATA	QA Contact:	Kedar Bidarkar <kbidarka>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.0.0	CC:	achan, dmacpher, jrist, omaciel
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	If an exception occurs in the middle of applying a subscription to an activation key, the subscription pool is removed from the activation key without any errors. This fix now only removes subscription pools from the activation keys if the resource pool is not found. Any exceptions that occur do not remove the pool.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-04 19:53:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Eric Helms 2012-08-13 19:17:53 UTC

Description of problem:
If a find pools is performed for an Activation Key and an exception is thrown the pools associated with the Activation Key are removed.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create an Activation Key
2. Apply a subscription to the activation key
3. Perform an action that causes an exception while registering a system (e.g. turn off the Candlepin Service)
4. Register a system using the activation key
  
Actual results:
The client should receive an error message of the form "Error updating system data, see /var/log/rhsm/rhsm.log for more details."  Viewing the activation key in the UI should result in the previously added subscription not being displayed under Applied Subscriptions.

Expected results:
The Applied Subscriptions should not be removed from the Activation Key.

Additional info:

Comment 1 Tom McKay 2012-08-29 19:07:09 UTC

  Branch: refs/heads/master
  Home:   https://github.com/Katello/katello
  Commit: 9f57f868233dd69b512f5d44db375644a902cb8e
      https://github.com/Katello/katello/commit/9f57f868233dd69b512f5d44db375644a902cb8e
  Author: Tom McKay <thomasmckay>
  Date:   2012-08-29 (Wed, 29 Aug 2012)

To test, 'service tomcat6 stop' to halt candlepin and then view subscriptions in an activation key. Previously this would wipe all subscriptions, leaving act key empty. This no longer happens.

Comment 3 Kedar Bidarkar 2012-09-23 12:46:50 UTC

I face this issue upon stopping Candlepin service, "Connection refused - connect(2)". Do we have any other way of testing this.

[root@dhcp201-200 ~]# service tomcat6 status
tomcat6 (pid 8917) is running...                           [  OK  ]
[root@dhcp201-200 ~]# service tomcat6 stop
Stopping tomcat6:                                          [  OK  ]
[root@dhcp201-200 ~]# katello -u admin -p admin activation_key info --org=redhat --name=act1_197_keys
Connection refused - connect(2)
[root@dhcp201-200 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Comment 4 Tom McKay 2012-09-24 12:53:10 UTC

This BZ is in the UI. Start up the UI and go to the act key page. Now stop tomcat6 and then refresh the page. Previously in this case all subs in an act key would be removed. This is now fixed so that when tomcat6 is restarted, the act key will remain as it was previously.

Comment 5 Kedar Bidarkar 2012-09-26 09:24:27 UTC

I think, I should have uploaded even this UI screenshot earlier.

On stopping tomcat6 and refreshing the page get the message 
"Connection refused - connect(2)"

But the act key remains intact upon starting tomcat6 service and could register the system.


[root@XXXX ~]# subscription-manager register --org redhat --activationkey act3_197_keys
The system has been registered with id: e545a5d3-0196-4d8a-9f05-71cb6ec86e2e

Comment 6 Kedar Bidarkar 2012-10-04 12:07:25 UTC

Can you please comment as to whether the above behaviour is right.

Comment 7 Tom McKay 2012-10-04 12:13:27 UTC

Yes, that is the expected behavior. Thanks!

Comment 9 errata-xmlrpc 2012-12-04 19:53:28 UTC

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