[Pulp-dev] migration tool for Pulp 3

[Sean Myers]

On 04/18/2017 04:16 PM, David Davis wrote:
> Comments inline.
> 
> David
> 
> On Tue, Apr 18, 2017 at 2:42 PM, Dennis Kliban <dkliban at redhat.com> wrote:
> 
>> Do we want to provide a tool for migrating from Pulp 2 to 3? If yes, then
>> ...
>>
>> Would the tool be able to migrate repository definitions and require the
>> user to sync and upload content to restore /var/lib/pulp/content?
>>
>>
> Question: is the structure of /var/lib/pulp/content changing in Pulp 3? If
> not, that might simplify the migration process.

Early discussion around the migration process concluded that the best possible
outcome for the migration process from 2 to 3, with respect to the content dir,
would be that no content is moved during the process. I belive jortel started
this effort in writing out the Artifact model, using the same filesystem
layout that we do in pulp 2.

>> Would this tool support installing Pulp 3 along side Pulp 2 and performing
>> a migration of database and /var/lib/pulp/content?
>>
>>
> I think we should allow for at least part of the installation process to be
> performed while Pulp 2 is running. We had a very painful process I think it
> was with Pulp 2.8 where users had to take their katello installations
> offline for hours or sometimes days. We should try to avoid that as much as
> possible by allowing part of the install to run while Pulp is running.

+1

The mongo role was not left in the dev playbook accidentally for pulp 3, live
migration from mongo to postgres should be the goal.

>> Would this tool be able to accept a mongodump of Pulp 2 MongoDB and a path
>> to a copy of Pulp 2's /var/lib/pulp directory and use that information to
>> populate Pulp 3?
>>
>>
>>
> I would say:
> 
> - For the mongo data, use whatever is set in pulp’s config but allow users
> to override it and specify a mongo connection or mongodump.
> - For the pulp filesystem content, use /var/lib/pulp but allow users to
> override this too.

+1

Both methods should be supported (live migration or from a mongodump), and
things like having a different fs layout than normal should also be supported.

It's also worth pointing out, though perhaps it goes without saying, that the
migration process is hugely important. When conflicts arise where the Pulp 2
data cannot be "fit" into the Pulp 3 data model, I think the default should be
to adjust Pulp 3 to make it work, in general favoring a better user experience
for the migration over a "pure" data model. Hopefully, though, we can have
both.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170418/1665a0b2/attachment.sig>