Project

Profile

Help

Issue #6555

closed

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 almost 4 years ago. Updated over 3 years 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.

Also available in: Atom PDF