Planning: design pulp3 approach to task tags
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.
#5 Updated by bmbouter over 4 years ago
FYI, some filtering is already provided here: https://github.com/pulp/pulp/blob/3.0-dev/platform/pulp/app/viewsets/task.py
#10 Updated by daviddavis over 4 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.
#11 Updated by daviddavis over 4 years ago
After getting some feedback on pulp-dev, here's the implementation proposal:
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.
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 to any object in Pulp that a task can act on (repositories, publishers, etc).
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)
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.