Bug 489556 - multi-org, trusts once trusts are in use, admin is unable to remove trust
multi-org, trusts once trusts are in use, admin is unable to remove trust
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Other (Show other bugs)
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Shannon Hughes
wes hayutin
Depends On:
Blocks: 456998
  Show dependency treegraph
Reported: 2009-03-10 13:22 EDT by wes hayutin
Modified: 2009-09-10 15:48 EDT (History)
4 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-10 15:48:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
WEB TRACEBACK from test1182.test.redhat.com (10.04 KB, text/plain)
2009-07-31 16:15 EDT, Brandon Perkins
no flags Details

  None (edit)
Description wes hayutin 2009-03-10 13:22:33 EDT
Description of problem:


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 16:00:39 EDT
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 


- 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 

  - 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 13:58:21 EDT
cant reproduce on the 3/23 build.. 
moving back to on_qa for further testing
Comment 3 wes hayutin 2009-03-30 15:15:33 EDT
Comment 4 Brandon Perkins 2009-07-31 16:14:44 EDT
Fails QA as I get an ISE when trying to remove the trusts.  Traceback attached.
Comment 5 Brandon Perkins 2009-07-31 16:15:41 EDT
Created attachment 355856 [details]
WEB TRACEBACK from test1182.test.redhat.com
Comment 6 Brandon Perkins 2009-07-31 16:41:27 EDT
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 17:29:39 EDT
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-07-31 22:36:57 EDT
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..

Comment 9 Shannon Hughes 2009-08-03 11:01:09 EDT
this is a dup...going to move to modified if you want to retest.
Comment 10 Shannon Hughes 2009-08-07 14:15:17 EDT
mass move to onqa
Comment 11 wes hayutin 2009-08-10 10:12:08 EDT
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 11:03:07 EDT
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.


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 15:48:40 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.