Project

Profile

Help

Task #2323

Updated by jortel@redhat.com about 4 years ago

In 2.8, pulp standardized how the platform determines where a content unit is stored under /var/lib/pulp/content. In the past, each plugin determined this on its own so it varied. To achieve consistency, a migration was added in 2.8 that recalculated the storage path for all content units created before the upgrade. Then, moved the file(s) and recreated the published symlinks. The migration was tuned for maximum performance against an installation containing 500k units and 1.5 million symlinks. However, as it turns out, there are larger customer with an estimated 5-10 million symlinks. To make matters worse, both the content and links are on an NFS share. The result is customer reports of the upgrades (migration) taking days and weeks.

It's important to note that pulp does not need this migration for correctness. The content unit storage path is stored in the DB and having a combination of old and new style storage paths does not cause problems. However, there is a use case that needs to be supported. Mainly for developers, sales and support users, not customers. That is: "As a user, I want to restore /var/lib/pulp/content from an archive so I don't need to re-download content ."

The proposal is to provide a way to disable (skip) this migration in Satellite installations. It's not needed for correctness and Satellite customers don't care about the restore use case.

But what about upstream pulp?

We have a few options here:

h2. Option #1:

Disable (skip) the migration based on installation environment. The default would be to perform the migration. Not sure how to detect this. Could use an environment variable but not sure how it would get set in all cases. Sometimes admins run pulp-manage-db directly. Perhaps something else? Something that already exists? Something persistent?

+Pros:+
* Least code changed and migration would happen as part of upgrade when desired.

+Cons:+
* How to detect when the migration is to be skipped.
* Can't migrate later (after upgrade) if you change your mind.
* This may require downstream work.

h2. Option #2:

Remove the migration code all together and provide a script to perform the migration after the upgrade as needed to support the use case.

+Pros:+
* Cleaner and less gimmicky.
* Admin can skip the migration to expedite upgrade and then do the migration later when system is idle. Though, ensuring the system is idle would be hard.
* Separate script provides better opportunity for good progress reporting and users could run the migration is small batches.

+Cons:+
* More development needed.
* Admins will likely not run the migration voluntarily unless they need/want to support the restore use case. This does not advance the pulp team's desire for broad /var/lib/pulp/content filesystem layout consistency. And there is value in this consistency.

Other options?

Thoughts? Comments?

Back