Project

Profile

Help

Task #2482

Planning: design pulp3 approach to task tags

Added by ttereshc almost 3 years ago. Updated 6 months ago.

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

0%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 22

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.


Checklist


Related issues

Duplicated by Pulp - Task #2636: Planning: design pulp3 approach to task tags. CLOSED - DUPLICATE Actions

History

#1 Updated by ttereshc over 2 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)

#2 Updated by ttereshc over 2 years ago

  • Duplicated by Task #2636: Planning: design pulp3 approach to task tags. added

#3 Updated by ttereshc over 2 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.

#4 Updated by mhrivnak over 2 years ago

  • Groomed changed from No to Yes
  • Sprint Candidate changed from No to Yes

#5 Updated by bmbouter over 2 years ago

#6 Updated by mhrivnak over 2 years ago

  • Sprint/Milestone set to 39

#7 Updated by mhrivnak over 2 years ago

  • Sprint/Milestone changed from 39 to 40

#8 Updated by daviddavis over 2 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to daviddavis

#9 Updated by mhrivnak over 2 years ago

  • Sprint/Milestone changed from 40 to 41

#10 Updated by daviddavis over 2 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 2 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 relation1 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

#12 Updated by jortel@redhat.com over 2 years ago

Suggest resource_id instead of object_id for FK to the resource.

#13 Updated by daviddavis over 2 years ago

  • Status changed from ASSIGNED to CLOSED - COMPLETE

#14 Updated by bmbouter over 1 year ago

  • Sprint set to Sprint 22

#15 Updated by bmbouter over 1 year ago

  • Sprint/Milestone deleted (41)

#16 Updated by daviddavis 6 months ago

  • Sprint/Milestone set to 3.0

#17 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF