Pulp

A couple items:

• add_many and remove_many seem vague. I was thinking about something like add_content_units and remove_content_units.
• Is the order of the actions (add, remove, then sync) correct? I thought we discussed sync, add, remove in the past.

I talked a bit with @dkliban and it seems like the order should be sync, add, then remove. For instance, suppose I have a version that was synced that contains units A and B. If I want to sync again to get unit C but also remove unit B, then I can't actually remove B (because sync will just re-add it). I thinks users would be surprised if they called sync and remove B, only to find that B was still there because it was removed before sync and then sync re-added it.

daviddavis@redhat.com wrote:

I talked a bit with @dkliban and it seems like the order should be sync, add, then remove.

This makes sense to me. +1 to doing it in this way.

I would move - define a detail route on the Importer ViewSet for 'sync' that accepts a 'repository' POST body parameter one level up or it seems like it's a part of requirements for the sync task.

Resource reservation should probably also be on a repo version, what do you think?

s/task's created list/task.created_resources

If we are going to lock on the repository version being created, then the repository version needs to be created in the viewset. A lock on the repository should prevent a repository version from being deleted from under it. Please correct me if my understanding of the locking is wrong.

To align w/ the locking that core would do as part of #3186. We need to tell them to lock on:

• The repo version
• The repository itself
• The importer being used

The lock on the repository version is needed in addition to serialize any concurrent publishes that may also try to publish on that version. If that case is prevented due to the a publication not being allowed while complete=False then the lock would not be required.

We should definitely prevent publishing a repository version with complete=False. We would also need to lock on repository when deleting a repository version. Based on info in https://pulp.plan.io/issues/3219 we are planning to do that. With this in mind, I don't think we need to lock on a repository version during a sync.

We do still need to lock on repo version. Otherwise, the version can be deleted, or the version before it could be deleted, which would modify the version in question.

So how publish task will behave if it sees incomplete repo version?
Without lock on a repo version the publish task will run and fail? Or it won't be possible to create a publish task for incomplete repo version?

If sync task will lock on repo version then a publish task can be created and wait in a queue.