Bug 489556

Summary: multi-org, trusts once trusts are in use, admin is unable to remove trust
Product: Red Hat Satellite 5 Reporter: wes hayutin <whayutin>
Component: OtherAssignee: Shannon Hughes <shughes>
Status: CLOSED CURRENTRELEASE QA Contact: wes hayutin <whayutin>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 530CC: bperkins, cperry, jsefler, shughes
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: https://grandprix.rhndev.redhat.com/rhn/admin/multiorg/OrgTrusts.do?oid=28
Whiteboard:
Fixed In Version: sat530 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-10 19:48:40 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: 456998    
Attachments:
Description Flags
WEB TRACEBACK from test1182.test.redhat.com none

Description wes hayutin 2009-03-10 17:22:33 UTC
Description of problem:

Satellite-5.3.0-RHEL5-re20090306.2-i386-embedded-oracle.iso

recreate:
Run multi-org2 automation through test public void test08_05_MultiOrg2_RemoveTrust_CheckSharedChannelRemoved_InOverview

manual recreate:
1. create 4 orgs
2. Org A, trusts org1,org2,org3
3. Share a channel from orgA
4. other orgs consume the channel, and register a system w/ shared channel as base
5. remove trusts

expected results:
trusts removed

actual results:
trusts are not removed

Comment 1 Brad Buckingham 2009-03-24 20:00:39 UTC
When I attempt a similar test with the latest code, it seems that the trusts are removed.  Below is my scenario:

1. Created 3 orgs (org2, org3, org4)

2. In the base org (org=1)
   - added org2, org3, org4 to the base org's trust (Admin->Trusts)
   - cloned the rhel5 base channel
   - via Manage Software Channels, modified the cloned channel to set the channel
     to 'public'

3. Registered a system to each org2, org3, org4 and set the base channel for each 
   of these systems to be the 'shared' channel from step 2.

4. In the base org (org=1), removed the trust from org2, org3 and org4 via the 
   Admin->Trusts.

Observations:

- the trust was removed from org2, org3 and org4. (i.e. no longer trusted 
  according to Admin->Trusts)

- from org2, org3, org4:

  - Channels: the shared cloned channel no longer appears in the list of 
    channels

  - Systems: the system still has the shared channel as it's base channel; 
    however, the system no longer has that as an option to select in "Alter 
    Channel Subscriptions"


Is this consistent with what you see?

Comment 2 wes hayutin 2009-03-27 17:58:21 UTC
cant reproduce on the 3/23 build.. 
moving back to on_qa for further testing

Comment 3 wes hayutin 2009-03-30 19:15:33 UTC
verified

Comment 4 Brandon Perkins 2009-07-31 20:14:44 UTC
Fails QA as I get an ISE when trying to remove the trusts.  Traceback attached.

Comment 5 Brandon Perkins 2009-07-31 20:15:41 UTC
Created attachment 355856 [details]
WEB TRACEBACK from test1182.test.redhat.com

Comment 6 Brandon Perkins 2009-07-31 20:41:27 UTC
In response to myself in Comment #4, I did something slightly different than the original steps (which I just missed).  I actually subscribed the system with a shared parent AND child in all orgs.  The traceback indicates the problem is with unsubscribing the children.   So this isn't exactly the same issue, but I thought it would be okay to piggy-back it to check both ways.

Comment 7 John Sefler 2009-07-31 21:29:39 UTC
re-verified stage build 7/24
I agree with all of the observations by brad in Comment#1 except that at the
end after the trust was removed...

 - Systems: the system no longer shows the shared channel as it's base channel;
   instead it is set to (none) and the shared channel is not an option to
   select in "Alter  Channel Subscriptions"

This is actually better behaviour than observed by Brad.

Therefore I would pass this bug as fixed in build 7/24 with respect to the scenario outline in the problem description and Comment #1.

However, as pointed out by Brandon in Comment #6, if you tweak the scenario to include shared child channels and then remove the trusts, an ISE is indeed thrown.  Failure confirmed.

Comment 8 wes hayutin 2009-08-01 02:36:57 UTC
removing the trusts while system's have subscribed base and child children is actually a duplicate issue that Shannon just put a fix in for.  IMHO is that this bug is a dup.  I'm not changing the status, waiting for dev to comment and double check.

This bug was actually created first.. so we're assigning the duplicate label to the wrong bug.. but so it goes..

https://bugzilla.redhat.com/show_bug.cgi?id=494409

Comment 9 Shannon Hughes 2009-08-03 15:01:09 UTC
this is a dup...going to move to modified if you want to retest.

Comment 10 Shannon Hughes 2009-08-07 18:15:17 UTC
mass move to onqa

Comment 11 wes hayutin 2009-08-10 14:12:08 UTC
this ise is fixed and the trusts can be removed.
Once the trust is removed however, shared base channels that have been subscribed by consuming orgs remain in view in the sdc.  The child channels are appropriately removed, just not the base channel

That issue should probably be covered by another bug, its not critical.  I'll discuss w/ shughes.

moving to verified

Comment 12 John Sefler 2009-08-14 15:03:07 UTC
Re-verified in staged (Satellite-5.3.0-RHEL5-re20090724.0) with pushed package updates from Aug 12

Following the scenario as described in Comment #1 and/or its variation described in Comment #6, no ISE is being thrown.

moving to RELEASE_PENDING


However, when admin is removing the trusts, if admin decides to remove the trusts in reverse (trust removal from the consuming org to the providing org - e.g. click on org2 and untrust org1 who owns the shared channels) then the behavior observed by Wes in Comment #11 occurs...  The base channel provided by org1 is still viewable by org2.  This is being fixed by buf 494409 comment #14.

Comment 13 Brandon Perkins 2009-09-10 19:48:40 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html