Red Hat Bugzilla – Bug 489556
multi-org, trusts once trusts are in use, admin is unable to remove trust
Last modified: 2009-09-10 15:48:40 EDT
Description of problem:
Run multi-org2 automation through test public void test08_05_MultiOrg2_RemoveTrust_CheckSharedChannelRemoved_InOverview
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
trusts are not removed
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
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
Is this consistent with what you see?
cant reproduce on the 3/23 build..
moving back to on_qa for further testing
Fails QA as I get an ISE when trying to remove the trusts. Traceback attached.
Created attachment 355856 [details]
WEB TRACEBACK from test1182.test.redhat.com
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.
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.
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..
this is a dup...going to move to modified if you want to retest.
mass move to onqa
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
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.
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.