Task #2482
closedPlanning: design pulp3 approach to task tags
0%
Description
In 2.y line there were action and resource tags.
Task tags are for the filtering of tasks, to support scenarios like:
As a user of the task search API
- I want to search for all tasks that operated on repo zoo.
- I want to search for all pubish tasks.
- I want to search for all publish tasks on repo zoo.
- I want to search all publish tasks performed by a particular publisher.
mhrivnak suggests to use task name for the purpose of action tag. (+1 for that)
Something similar to resource tag is also needed.
One idea is to add a repository to the task model as a foreign key because in most cases tasks are operated on a particular repo. There is at least one exception here, it is applicability calculation, which may or may not be bound to a particular repo.
Another concern is that it's possible that not only repository will be a resource by which search is performed. One may want to search by publisher, for example.
Upon agreement on how tags will be implemented in Pulp 3, create redmine stories to implement the chosen approach.
Related issues
Updated by ttereshc over 7 years ago
- Tracker changed from Story to Task
- Subject changed from Add tags to tasks in Pulp 3 to Planning: design pulp3 approach to task tags
- Description updated (diff)
Updated by ttereshc over 7 years ago
- Has duplicate Task #2636: Planning: design pulp3 approach to task tags. added
Updated by ttereshc over 7 years ago
@jortel's proposal from the duplicated task:
I propose using the resource name (model class) and build the ID part of the tag using the natural_key_fields.
Updated by mhrivnak over 7 years ago
- Groomed changed from No to Yes
- Sprint Candidate changed from No to Yes
Updated by bmbouter over 7 years ago
FYI, some filtering is already provided here: https://github.com/pulp/pulp/blob/3.0-dev/platform/pulp/app/viewsets/task.py
Updated by daviddavis over 7 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to daviddavis
Updated by daviddavis over 7 years ago
Here are the three user stories I think we need:
- As an authenticated user, I can see what resource(s) a task acted on.
- As an authenticated user, I can search for a tasks based on what resource they acted on.
- As an authenticated user, I can view a task's name and search for tasks based on their names.
Updated by daviddavis over 7 years ago
After getting some feedback on pulp-dev, here's the implementation proposal:
Background¶
Currently in Pulp 2, there are two types of task tags: action and resource. Action tags indicate the action being performed (sync, publish, etc), while resource tags indicate the resource type (repository, publisher, etc) and the resource id of the resource being acted upon.
Proposal¶
In Pulp 3, we ought to get rid of tags. For action tags, we'll simply add a field named "name" to the task table. This will store information about which action the tag is performing (sync, publish, etc). These names should correlate directly to what the task names are in celery.
For resource tags, these will be replaced with Task Resources. Like resource tags, these will be a many-to-one relationship to tasks (ie a task can have many task resources). These Task Resources then have a many-to-one generic relation[1] to any object in Pulp that a task can act on (repositories, publishers, etc).
Database Tables¶
Task
---
...
name - varchar
TaskResource
---
id - uuid
task_id - uuid (foreign key to a task)
content_type - varchar (e.g. "Repository")
resource_id - uuid (generic foreign key to a repo/publisher/etc)
Rest API¶
For task names, this field will be returned when querying tasks and can also be filtered, etc when searching tasks. Pretty straightforward.
For Task Resources, Task information will be returned along with a list field such as "resources." This field will be a list of hrefs that point to each resource's REST API url (e.g. /api/v3/repositories/zoo/). For filtering Tasks by Task Resources, users will supply the url of the resource they wish to filter by.
[1] https://docs.djangoproject.com/en/1.11/ref/contrib/contenttypes/#generic-relations
Updated by jortel@redhat.com over 7 years ago
Suggest resource_id instead of object_id for FK to the resource.
Updated by daviddavis over 7 years ago
- Status changed from ASSIGNED to CLOSED - COMPLETE