Pulp

For option 1, we could have pulp-manage-db take a special script that causes the migration to be a no-op.

We should not do option 2 because we want all pulp users to use the new filesystem layout. A separate script should be published but we should not remove the migration. So in other words we should do option 1 and 2 with the adjustment that option 2 not remove the migration code.

This story needs more discussion before it leaves the NEW state. We need a plan before work begins.

I like the possibility this suggest brings. Can you elaborate on what this option might look like for pulp-manage-db? Each plugin has this migration so they would all (4-5) likely need to be skipped for most satellite customers. The penalty for not including the skip option could be very high. When run with satellite tooling, it would automated but worried about cases where sat admins run pulp-manage-db directly.

It could be called like this:

pulp-manage-db --skip-filesystem-migration

It would skip any of the associated filesystem layout migrations depending on which ones are installed.

One option is to have pulp-manage-db read a file at startup that would contain a list of migrations to skip. That's generic and would let us guarantee that users won't forget to use a specific option if they run it manually.

mhrivnak wrote:

One option is to have pulp-manage-db read a file at startup that would contain a list of migrations to skip. That's generic and would let us guarantee that users won't forget to use a specific option if they run it manually.

That sounds better than what I proposed. Since the 2.y migration system only records the most recent migration level running it once would cause all future runs to also skip. Right?

mhrivnak wrote:

One option is to have pulp-manage-db read a file at startup that would contain a list of migrations to skip. That's generic and would let us guarantee that users won't forget to use a specific option if they run it manually.

I like this option. It's generic from the upstream perspective and solves the problem. We'd need to document appropriately to ensure it's never used by end users. The potential for abuse is high. Imagining something like /etc/pulp/migration/blacklist.txt that contains a list of migrations to no-op.

Considering the following minimal patch for these reasons:

• The most minimum code changes needed to accomplish the goal. This minimizes possibility of merge conflicts applying the patch.
• Targeting only the migrations causing the pain.
• Some of the migrations include fixes to regressions when converting to mongoengine.

[jortel@f23d pulp_rpm]$ git diff -p
diff --git a/plugins/pulp_rpm/plugins/migrations/0028_standard_storage_path.py b/plugins/pulp_rpm/plugins/migrations/0028_standard_storage_path.py
index 08049ec..327428c 100644
--- a/plugins/pulp_rpm/plugins/migrations/0028_standard_storage_path.py
+++ b/plugins/pulp_rpm/plugins/migrations/0028_standard_storage_path.py
@@ -23,11 +23,11 @@ def migrate(*args, **kwargs):
     _logger.info(stars)

     migration = Migration()
-    migration.add(rpm_plan())
-    migration.add(srpm_plan())
-    migration.add(drpm_plan())
-    migration.add(YumMetadataFile())
-    migration.add(DistributionPlan())
+    # migration.add(rpm_plan())
+    # migration.add(srpm_plan())
+    # migration.add(drpm_plan())
+    # migration.add(YumMetadataFile())
+    # migration.add(DistributionPlan())
     migration.add(ISO())
     migration()

jortel@redhat.com wrote:

Considering the following minimal patch for these reasons:

• The most minimum code changes needed to accomplish the goal. This minimizes possibility of merge conflicts applying the patch.
• Targeting only the migrations causing the pain.
• Some of the migrations include fixes to regressions when converting to mongoengine.

[...]

After further consideration, this really could be patched as a noop in the platform instead. Any of the corrections made in the plugin migrations would only fix issues with early 2.8.0 betas. Satellite 6.2 upgrades would only involve later matured pulp 2.8 that did not create units with these issues. Including another patch shortly.

Considering this for a patch:

diff --git a/pulp/plugins/migration/standard_storage_path.py b/pulp/plugins/migration/standard_storage_path.py
index f651e71..90f814e 100644
--- a/pulp/plugins/migration/standard_storage_path.py
+++ b/pulp/plugins/migration/standard_storage_path.py
@@ -392,6 +392,11 @@ class Migration(object):
           1. Batch the migration.
           2. Delete empty directories created by the migration.
         """
+
+        # Re: Bug:1381702
+        _log.info('Path migration skipped.')
+        return
+
         batch = Batch()
         for unit in chain(*self.plans):
             batch.add(unit)