Project

Profile

Help

Story #2409

closed

As an API user, a call to update an Publisher generates a Task

Added by ttereshc over 7 years ago. Updated over 4 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
Sprint:
Sprint 21
Quarter:

Description

We need to create an update task which can live in pulp.app.tasks.publisher.

Task name in Pulp 2: `pulp.server.tasks.repository.distributor_update`.
Task implementation in Pulp 2: https://github.com/pulp/pulp/blob/3.0-dev/server/pulp/server/controllers/distributor.py#L184


Related issues

Related to Pulp - Task #2380: Create a redmine task for each 2.y celery task to be converted to 3.0CLOSED - CURRENTRELEASEttereshc

Actions
Actions #1

Updated by ttereshc over 7 years ago

  • Related to Task #2380: Create a redmine task for each 2.y celery task to be converted to 3.0 added
Actions #2

Updated by ttereshc over 7 years ago

  • Tags Pulp 3 added
Actions #3

Updated by mhrivnak over 7 years ago

  • Groomed changed from No to Yes
  • Sprint Candidate changed from No to Yes
Actions #4

Updated by mhrivnak over 7 years ago

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.

Actions #5

Updated by mhrivnak almost 7 years ago

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.

Actions #6

Updated by jortel@redhat.com almost 7 years ago

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.

Actions #7

Updated by bmbouter almost 7 years ago

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.

Actions #8

Updated by bmbouter almost 7 years ago

  • Tracker changed from Task to Story
  • Subject changed from Convert celery task repository.distributor_update to Pulp 3 to As an API user, a call to update an Publisher generates a Task
  • Description updated (diff)

Rewriting based on similarity to issue 2756 and discussion on the mailing list: https://www.redhat.com/archives/pulp-dev/2017-May/msg00014.html

Actions #9

Updated by mhrivnak almost 7 years ago

  • Sprint/Milestone set to 39
Actions #10

Updated by amacdona@redhat.com almost 7 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to amacdona@redhat.com
Actions #11

Updated by mhrivnak almost 7 years ago

  • Sprint/Milestone changed from 39 to 40
Actions #12

Updated by mhrivnak almost 7 years ago

  • Status changed from ASSIGNED to POST

Added by amacdona@redhat.com over 6 years ago

Revision e81d0a63 | View on GitHub

Dispatch a task to update publishers.

closes #2409

Added by amacdona@redhat.com over 6 years ago

Revision e81d0a63 | View on GitHub

Dispatch a task to update publishers.

closes #2409

Actions #13

Updated by amacdona@redhat.com over 6 years ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100
Actions #14

Updated by bmbouter about 6 years ago

  • Sprint set to Sprint 21
Actions #15

Updated by bmbouter about 6 years ago

  • Sprint/Milestone deleted (40)
Actions #16

Updated by daviddavis almost 5 years ago

  • Sprint/Milestone set to 3.0.0
Actions #17

Updated by bmbouter almost 5 years ago

  • Tags deleted (Pulp 3)
Actions #18

Updated by bmbouter over 4 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF