Pulp

Does a repo delete still need to be run by the tasking system or could it be a CRUD operation in the view layer only?

• For example the model layer will cascade delete all importers and publishers when a repo is deleted because of this¹.
• The exception handling is now handled centrally so this task doesn't need to deal with that
• The consumer actions are no longer in Pulp3

The only area that may continue to be needed could be the group membership stuff, but adding that could be the responsibility of the work to implement to group stuff correctly.

[0]: https://github.com/pulp/pulp/blob/c3e4e6514748ad24df27f64303ba3f226dc3f396/server/pulp/server/controllers/repository.py#L518-L519
[1]: https://github.com/pulp/pulp/blob/8c23b326cdb7739c420fdff8538a66e73147e0fb/app/pulp/app/models/repository.py#L112

bmbouter wrote:

Does a repo delete still need to be run by the tasking system or could it be a CRUD operation in the view layer only?

Great question, and one that's been on my mind also. I think there are two reasons why pulp 2 has similar CRUD operations in tasks.

1) to update consumers. It really just needs to queue tasks to update the consumers, but that itself can take some time.

2) to ensure that a repo does not get deleted (or modified, importer/publisher included) while some other task is operating on it, such as a sync.

Reason 1 won't apply in pulp 3. But much of reason 2 still applies. I would like to do some CRUD operations not as tasks, and have sync/publish/etc tasks be prepared to deal with that (by using some combination of a transaction, and just loading what it needs once up-front and never again). But that brings its own set of edge cases, and it seems easier and safer to stick with the current model of doing most repo UD with the safety of a resource lock.

What is the status with repo sync/publish result collections, are we going to create those in the future or we have some other plans?
https://github.com/pulp/pulp/blob/3.0-dev/server/pulp/server/controllers/repository.py#L527-L528

I think we are deliberately omitting that from the MVP so we can think about better ways to store similar history.