Project

Profile

Help

Issue #6555

Story #6134: [EPIC] Pulp import/export

Investigate/decide whether "set last_export to null explicitly before allowing exporter to be deleted" is a Good Idea

Added by ggainey 5 months ago. Updated about 2 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
Yes
Sprint Candidate:
No
Tags:
Sprint:
Sprint 77
Quarter:

Description

From discussion started while writing functional tests :

pulpcore/tests/functional/api/using_plugin/test_pulpexport.py
        if path.exists(exporter.path):
            shutil.rmtree(exporter.path)
        # NOTE: you have to manually undo 'last-export' if you really really REALLY want to
        #  delete an Exporter. This is...probably correct?
 @daviddavis
Hmm. I think deleting the exporter should just cascade delete the exports?

 @ggainey
We protect from deleting the last_export of a PulpExporter (see https://github.com/pulp/pulpcore/blob/master/pulpcore/app/models/exporter.py#L198) - iirc that kept PulpExporter from being deleted if it had ever been exported, unless/until you explicitly set last_export to null first. I will experiment some more tho, a lot happened between when I wrote that comment and now.

 @daviddavis
Ok. I do see value in preventing a user from accidentally deleting an exporter that has exported but unsetting a field to delete an object seems weird.

 @ggainey
You are not wrong. There is probably a better way to do this, will leave this comment open and think about it overnight.

 @daviddavis
Ok sounds good. I'm fine with leaving it this way as long as it's clear to the user that the last_export has to be unset in order to delete.

Decide if this is appropriate. If not, decide what the right thing to do is, and use this issue to get the change checked in.

Associated revisions

Revision e00d176a View on GitHub
Added by ggainey 3 months ago

Changed PulpExporter.last_export from PROTECTED to SET_NULL.

fixes #6555

Revision e294b823 View on GitHub
Added by ggainey 2 months ago

Changed PulpExporter.last_export from PROTECTED to SET_NULL.

fixes #6555

(cherry picked from commit e00d176a90783cc757de025cb5be4f5b810645bc)

History

#1 Updated by rchan 5 months ago

  • Sprint changed from Sprint 71 to Sprint 72

#2 Updated by rchan 5 months ago

  • Sprint changed from Sprint 72 to Sprint 73

#3 Updated by rchan 4 months ago

  • Sprint changed from Sprint 73 to Sprint 74

#4 Updated by rchan 4 months ago

  • Sprint changed from Sprint 74 to Sprint 75

#5 Updated by rchan 3 months ago

  • Sprint changed from Sprint 75 to Sprint 76

#6 Updated by rchan 3 months ago

  • Sprint changed from Sprint 76 to Sprint 77

#7 Updated by ggainey 3 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to ggainey

daviddavis - having been bitten by this behavior a number of times now, I think I have convinced myself that 'special protection' for last_export is a) not actually all that useful, and b) very, very inconvenient for the main workflow of deleting an Exporter. With the addition of start_versions= and version=, one can recreate a last-export at will. I think I would like to remove this protection. Objections?

#8 Updated by daviddavis 3 months ago

I agree. +1

#9 Updated by pulpbot 3 months ago

  • Status changed from ASSIGNED to POST

#10 Updated by ggainey 3 months ago

  • Status changed from POST to MODIFIED

#12 Updated by dkliban@redhat.com about 2 months ago

  • Sprint/Milestone set to 3.6.0

#13 Updated by pulpbot about 2 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF