Bug 1123025 - [RFE] Would like rhn-migrate-classic-to-rhsm enhanced to accept migration-data from Sat5-to-Sat6 migration process
Summary: [RFE] Would like rhn-migrate-classic-to-rhsm enhanced to accept migration-dat...
Status: CLOSED DUPLICATE of bug 1196416
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: subscription-manager
Version: 7.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: alpha
: ---
Assignee: Alex Wood
QA Contact: John Sefler
Depends On:
Blocks: 1205796 rhsm-rhel72
TreeView+ depends on / blocked
Reported: 2014-07-24 16:15 UTC by Grant Gainey
Modified: 2015-07-12 08:19 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2015-04-07 15:37:47 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Grant Gainey 2014-07-24 16:15:36 UTC
[The following is a summary of discussion between ggainey and awood about the problems surrounding migration of Sat5 clients to a new Sat6 instance]

Description of problem:

Part of moving customer-data from their existing Satellite-5 instance to their shiny-new-Satellite-6 instance involves moving their System profiles to Content Hosts.

We would like to be able to accomplish a workflow something like the following:

* Export Sat5 system-profiles
* Import said profiles and create Sat6 content-hosts
* Generate a CSV file during this process containing the following data:
Sat5SID ; Sat6ConsumerId ; Sat6ActivationKey
* Have rhn-migrate-classic-to-rhsm be able to take advantage of said CSV, in order to attach a client to its related content-host on Sat6

Issues to be resolved around this:

* migrate-classic doesn't understand cloned channels. 

channels.software.getDetails(channelLabel) has a field, 'clone_original', which has the label of "the channel this channel was cloned FROM". For the migrate-classic chan-to-PEM mapping to work, the tool would have to be taught to follow that back until clone_orginal is empty (which would be the originating Red Hat channel) and *then* map.

* migrate-classic would need some way to be pointed at the created-CSV mentioned above, and find the entry for its own machine therein

* migrate-classic doesn't currently understand --consumerid or --activationkey

* The created-CSV would need to be placed into some location migrate-classic could pull it from, on the Sat6 system it is going to re-register to.

* Alternately (or perhaps in addition to the above), migrate-classic would need to be able to accept a pointer to said CSV as a local file.

This work would need to be available on RHEL5 and RHEL6 via errata released on or before the GA date of Sat6, in order to facilitate early-adopters' migration process.

Comment 7 Bryan Kearney 2014-08-27 18:50:25 UTC
moving to rhel7, since it will be carried in a sat channel until then

Comment 11 John Sefler 2014-10-28 17:41:50 UTC
This feature request was not implemented and delivered to QE by the rhel-7.1.0 Dev Freeze date of 10/27/2014.  Deferring for consideration in next release.

Comment 14 Devan Goodwin 2015-04-07 14:47:57 UTC
Hi Grant has this been addressed by migration data since this was filed?

Comment 15 Grant Gainey 2015-04-07 14:54:14 UTC
We ended up writing sat5to6 to get the 6.0 transition issue resolved. That is only available to sat5 users, iirc.

I believe Alex has been working on updates to rhn-migrate-to-rhsm that address some of what's in this BZ.  Alex?

Comment 16 Alex Wood 2015-04-07 15:37:47 UTC
Yes, bug 1086367, bug 1180273, and bug 1196416 should all handle various migration related enhancements.

Closing this as DUPLICATE of 1196416 even though this bug is actually a duplicate of several different bugs.

*** This bug has been marked as a duplicate of bug 1196416 ***

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