Bug 517173

The recommend way to do this scenario would be to use channel sharing feature. Since we dont restrict users from doing the imports to other orgs from rhn-satellite-exporter we should fix it. But we have two workarounds.

1. use rhn-satellite-exporter using --org-id or

2. Channel sharing feature through webui.

Since we have multiple workarounds. I don't consider this a blocker at this point.

*** Bug 543507 has been marked as a duplicate of this bug. ***

Not sure why Comment #1 was private, since it listed options. Going to make it public. 

Cliff

How does --org-id of exporter work? Would you not get the same problem trying to copy channels across organisations?

Solution (2) did not work as a workaround for me, because I need to clone the channel, which is not possible with a shared channel.

The problem described in this bug report is simply a technical limitation
of the Satellite multi-org implementation.

There are few things adding to the problem:

1. In the current Satellite schema, channel label has to be unique (across
the whole Satellite).

2. Every channel is tied to one particular organization (i.e. one channel
cannot be more copied from one org to another, it will always disappear
from one organization and appear in the new organization)

3. satellite-sync does updates in rhnChannelNewestPackage which we use
to find for every channel available, latest version of every package.

So when doing the procedure described in the initial comment, what happens
is:

1. the channel we're importing is moved from one organization to another,
while its channel.id stays the same.

2. the packages from the export are copied over to the new organization,
they all get new package.id

3. Sync tries to update rhnChannelNewestPackage, which is defined as:

Name                                      Null?    Type
 ----------------------------------------- -------- ------
 CHANNEL_ID                                NOT NULL NUMBER
 NAME_ID                                   NOT NULL NUMBER
 EVR_ID                                    NOT NULL NUMBER
 PACKAGE_ARCH_ID                           NOT NULL NUMBER
 PACKAGE_ID                                NOT NULL NUMBER

At this point, in the database we have at least two packages which:
- have same name_id, evr_id, package_arch_id and
- have different package_id and
- both of these packages want to belong to the same channel_id

Satellite sync tries to insert these two rows into the rhnChannelNewestPackage
table and violates the following constraint:

rhn_cnp_cid_nid_uq UNIQUE (channel_id, name_id, package_arch_id)

After this, the Satellite will be in a state where:

1. The channel moved from the old to the new organization

2. Packages in this channel are still the packages from the 
old organization.

(In reply to comment #4)
> How does --org-id of exporter work?

I'm sure Pradeep meant satellite-sync --orgid here (i.e. not the exporter).

For me : 

2. Channel sharing feature through webui.

This is why we have this feature, to allow you to easily share channels and their content over multiple Orgs. 

This combined with our ability to lock a channel in time (same as creating a dump) - by cloning the channel - should provide a work-flow anyone can use for Multi-Org Satellites. Customers have used QA > Stage > Prod work-flow for cloned channels for many years in Satellite. If you then breakup these cross-Org, the channel sharing capabilites allows you to extend/share those channels cross-Org as well. 

Suggested work-flow for some people would be :

create a channel in Org A - once your happy. 
 - Clone channel 
  - Share cloned channel to Other Orgs
  - On other orgs subscribe systems to new channel. 

You either then constantly repeat this process - re-subscribing to new cloned channels, as needed, or move content into the cloned channel when it is ready for consumption by others in the other Orgs. 

So:
 Org A - owns channels 
  - Master channel Foo 
   - Cloned channel Foo QA staged 
   - Cloned channel Foo QA 
   - Cloned channel Foo Stage staged
   - Cloned channel Foo Stage
   - Cloned channel Foo Prod staged
   - Cloned channel Foo Prod

QA channel Foo is shared to your QA org and systems, with select systems subscribed to the 'staged' channel before you move that content into main QA channel for all to consume for testing. 

This is the equivalant of taking a channel snapshot/dump in time and then importing it into another Org for them to consume. 

Where you have select systems subscribed to the 'staged' channels were content is tested before putting into the main channel for everyone else to consume. 

Depending on nature, you may choose to only have staged channel for the Prod instance where before releasing into prod they are given one final test before moving to prod. 

In short, due to nature of this issue with schema limitations at play - were not likely to try and address this until a major release of Satellite, such as 5.5, 6.0 or 6.1 and not as say part of 5.4.1 release. As such, moving back off the sat54-errata tracker to the sat600-triage tracker.

In the mean time as suggested initally two main alternatives noted in comment #1 and #10, but for me channel cloning and sharing is the best way to meet the same end result.

Cliff

The fix here is to remove stalled packages, i.e. those with orgid of original org, from the channel.

Fixed in spacewalk master by
commit 9cff05430de98e1f081fedd37559203e11e02bba
    517173 - unlink packages with different orgid

Fixed spacewalk package: spacewalk-backend-1.4.5-1

Backported to SATELLITE-5.4 as
commit 11a9521c05d128e3be2104de41cf183621d55113
    517173 - unlink packages with different orgid

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/RHBA-2011-1466.html