# Pulp 2to3 Migration overview

## Key concepts

- **Migration plan** defines what should be migrated from pulp2 and where into pulp3
- **Pre-migration** stage is responsible for making a "snapshot" of pulp22 data needed for migration and store it in the pulp3 db
- **Migration** stage is reponsible for creating all the necessary records in pulp3 db and moving artifacts into the pulp3 storage.
- *[not relevant for Satellite]* Migration can happen on **per-plugin basis**, aka one plugin is still working with pulp2, another is migrated and fully working with pulp3.
- Migration can be **re-run multiple times** and if not reset, it will always be **incremental**.

## Configuration
https://docs.pulpproject.org/pulp_2to3_migration/configuration.html

## REST API
https://docs.pulpproject.org/pulp_2to3_migration/restapi.html

* migration plan
* CRD for migration plan
* run migration based on migration plan
* reset migration based on a specific migration plan
* view a mapping of pulp2 content to pulp3 content
* view a mapping of a pulp2 repo to a pulp3 repo/version/remote/publication/distribution

## Tasks
- migrate_from_pulp2
* creates a task group and adds itself to it
* [performs pre-migration and migration](https://github.com/pulp/pulp-2to3-migration/blob/e243fcc21b16fcc4589027f8339bbef472bedb85/pulp_2to3_migration/app/tasks/migrate.py#L76-L82)

Pre-migration and content migration happens in one task (not to overload system with heavy parallel tasks and for data correctness, e.g. some content has content which depends on the other + ability to support incremental re-runs makes it less error-prone if it's happening in one task).
The last step of the task is responsible for creating repository versions, publications and distributions. This is happening after all content is migrated. This step triggers many tasks which run in parallel. There are as many tasks as there are repositories in pulp3(!), this is defined in the migration plan.

- reset_pulp3_data
Removes data from pulp 3 db for the plugins specified in a migration plan so the migration can be started from scratch and not be incremental.
It is a long task because resetting happens on per plugin basis with carefully picking and removing only pulp 3 data relevant to a specific plugin.
*[relevant for Satellite]* Potential improvement: a separate code path to remove all pulp 3 data.

## High-level flow of the migrate_from_pulp2 task

## Everything in detail

## Code related comments