Pulp

This may be trickier than it sounds. I think we still want DRF to figure out what changes to make based on the request body, but we want to defer that. There's a logical, and potentially important, difference between:

1. use DRF to figure out what changes to make
2. queue a task to make those changes later

and

1. queue a task with the response data
2. later, use DRF to figure out what changes to make, and make those changes immediately

The difference lies in the potential for the object to change between the time the request is made, and the task actually runs.

As such, this may be difficult to do without also considering the API integration. It might make sense to do both at the same time.

Given the challenge with the above, I wonder if we should allow updating of these configs via the REST API synchronously, and just expect anything that uses the config to be ok that it changes at any time. The tasks that use these configs will naturally want to load them just once anyway.

mhrivnak wrote:

Given the challenge with the above, I wonder if we should allow updating of these configs via the REST API synchronously, and just expect anything that uses the config to be ok that it changes at any time. The tasks that use these configs will naturally want to load them just once anyway.

Makes sense to me. I cannot think of any reason that updates to the importer/publisher resource would need to be long running or otherwise benefit from being asynchronous. Even in the case of DELETE. If an importer is deleted while there are queued sync tasks, it seems reasonable for those tasks to fail when resources cannot be fetched from the DB. As a user, I would expect that. On the flip side, if the DELETE is queued behind several sync tasks, the system get tied up syncing repositories that are intended to be be deleted.

After some good discussion we determined this will be done asynchronously. Info on that discussion can be seen here: https://www.redhat.com/archives/pulp-dev/2017-May/msg00014.html

I also believe we determined the user supplied data will be validated in the API using the serializer prior to dispatching the task. The update will apply when the task runs, and any issues that rise will be captured by the normal task failure handlers.