Task #2408
closed
Convert celery task repository.distributor_delete to Pulp 3
0%
Description
Task name in Pulp 2: `pulp.server.tasks.repository.distributor_delete`.
Task implementation in Pulp 2: https://github.com/pulp/pulp/blob/3.0-dev/server/pulp/server/controllers/distributor.py#L114
Related issues
Updated by ttereshc about 8 years ago
- Related to Task #2380: Create a redmine task for each 2.y celery task to be converted to 3.0 added
Updated by mhrivnak about 8 years ago
- Groomed changed from No to Yes
- Sprint Candidate changed from No to Yes
Updated by ttereshc about 8 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to ttereshc
Updated by ttereshc about 8 years ago
- Does anyone have suggestions where to put the code for celery tasks? Do we want to create 'controllers' subdirectory for that?
- Consumer model has many-to-many relationship with Publisher. Is it better to ignore this relationship for now or in this task we should consider deletion of related consumers as well?
Updated by bmbouter about 8 years ago
ttereshc wrote:
- Does anyone have suggestions where to put the code for celery tasks? Do we want to create 'controllers' subdirectory for that?
I'll suggest two options for this.
1. Put the actual code in pulp.tasking.tasks.repository.py and import the tasks themselves into pulp.tasking.registry so that it's discoverable. Note repository.py makes sense for this task but others may have consumer.py or applicability.py
2. Put the actual code in pulp.tasking.repository.py and import the tasks themselves into pulp.tasking.registry so that it's discoverable. Note repository.py makes sense for this task but others may have consumer.py or applicability.py
3. Make the registry.py[0] a Python package. The task code itself would then live somewhere like pulp.tasking.registry.repository.py and the task itself would be imported into pulp.tasking.registry.__init__.py so that it is discoverable. Note repository.py makes sense for this task but others may have consumer.py or applicability.py
I recommend either option 1 or 2.
- Consumer model has many-to-many relationship with Publisher. Is it better to ignore this relationship for now or in this task we should consider deletion of related consumers as well?
I would ignore this for now.
Updated by ttereshc almost 8 years ago
This task is also supposed to do some cleanup by plugin.
For example, here is what yum plugin does: https://github.com/pulp/pulp_rpm/blob/ef5fc5b2af47736114b68bc08658d9b2a94b84e1/plugins/pulp_rpm/plugins/distributors/yum/distributor.py#L87
Should we ignore it with some comment in code or another task in redmine for now?
Or maybe make a pre-delete signal which for now will be just a placeholder for the time when we will come up with the plugin API?
Added by mhrivnak almost 8 years ago
Added by mhrivnak almost 8 years ago
Revision 1ef8c359 | View on GitHub
Workers can run and execute tasks.
Thanks to ttereshc aka @goosemania who contributed some of this code.
There is a known issue that resource-reserving tasks still cannot run, but there is a fix in the works that will follow this PR.
Fixes bugs in pulp.tasking Rearranges pulp.tasking to put related code together Adds two tasks (importer and publisher delete) in pulp.app.tasks Fixes import order problems of django app vs. celery app
Updated by mhrivnak almost 8 years ago
- Status changed from ASSIGNED to MODIFIED
The pulp 2 implementation called a distributor method that gave it a chance to do cleanup. It's not clear if that will be valuable for pulp 3; that behavior will be added if necessary through the work on the plugin API.
Updated by bmbouter almost 5 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
.
Workers can run and execute tasks.
Thanks to ttereshc aka @goosemania who contributed some of this code.
There is a known issue that resource-reserving tasks still cannot run, but there is a fix in the works that will follow this PR.
Fixes bugs in pulp.tasking Rearranges pulp.tasking to put related code together Adds two tasks (importer and publisher delete) in pulp.app.tasks Fixes import order problems of django app vs. celery app
https://pulp.plan.io/issues/2440
re #2440 re #2400 re #2408