Project

Profile

Help

Story #7710

closed

As a user, I can use 'flush' after the migrations are applied and receive the required AccessPolicies

Added by bmbouter about 4 years ago. Updated almost 4 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
Groomed:
Yes
Sprint Candidate:
No
Tags:
Sprint:
Sprint 86
Quarter:

Description

Problem

As a user experienced if a user does the following they will have a problem:

  1. User runs migration and receives the AccessPolicy via a data migration like this one
  2. User then later calls 'flush' which keeps migrations marked as "run" but drops all data including the AccessPolicy
  3. User then tries to use Pulp, but receives AccessPolicy matching query does not exist.

Solution 1

Change where we recommend the AccessPolicy data is created.

  1. Stop doing it in migrations
  2. Instead do it in a post-migrate signal
  3. If the AccessPolicy is already in the db catch the Duplicate entry and move on
  • This would need to be changed in the plugin writer docs here
  • Also any existing AccessPolicy made in migrations would also have to be put here too. Currently that is only one, created in migration 42.

Solution 2:

Use a fixtures approach instead.

Actions #1

Updated by ttereshc about 4 years ago

Solution 1 seems more user-friendly since user doesn't need to do anything, however this will run with every django-migrate.

Solution 2 is a Django-native way to fill in the database, it's explicit and can be run on_demand. It's less user-friendly since it's one more step.

I hear a strong resistance in the community with regards to signals, so maybe solution #2 is the way.
I'm also somewhat concerned what to do if/when data model changes for the data we load in. Is any of the solutions provide a better way to handle that? and also a check that a certain migration applied before loading the data.

Actions #2

Updated by ttereshc about 4 years ago

https://docs.djangoproject.com/en/2.2/howto/initial-data/#providing-data-with-fixtures

Note this means that if you change one of the rows created by a fixture and then run loaddata again, you’ll wipe out any changes you’ve made.

It seems like fixture way handles existing data and it overwrites it in case someone changed any row.

Actions #3

Updated by bmbouter about 4 years ago

The overwriting nature of fixtures I think is not a good fit for this need because users can customize the AccessPolicy at any point and we can't overwrite it.

I also read the #django recommendation to not use signals, but I didn't read any evidence with it, so I put it into the fear, uncertainty, and doubt category. Solution 1 has a great user experience, so I think we should prototype solution 1 and see how reliable (or not) it is for us.

Actions #4

Updated by ttereshc almost 4 years ago

  • Sprint/Milestone set to 3.9.0
  • Groomed changed from No to Yes
  • Sprint set to Sprint 86
Actions #5

Updated by mdellweg almost 4 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to mdellweg
Actions #6

Updated by pulpbot almost 4 years ago

  • Status changed from ASSIGNED to POST

Added by mdellweg almost 4 years ago

Revision ee9e84ff | View on GitHub

Add access policies via post_migrate signal

fixes #7710 https://pulp.plan.io/issues/7710

Actions #7

Updated by mdellweg almost 4 years ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100
Actions #8

Updated by pulpbot almost 4 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF