On 04/18/2017 04:16 PM, David Davis wrote: > Comments inline. > > David > > On Tue, Apr 18, 2017 at 2:42 PM, Dennis Kliban <[email protected]> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
