[Pulp-dev] Task tagging in Pulp 3

David Davis daviddavis at redhat.com
Mon Nov 6 19:17:54 UTC 2017


Originally I scheduled a meeting for tomorrow but on second thought, I
figured a pulp-dev thread would be more inclusive than a meeting. I hope to
get this resolved by the end of this week and if not then maybe we can have
a meeting.

This is to design out the replacement of task tags in Pulp 3. I’ve got
feedback from a few other developers in terms of how to do that so I wrote
up a sort of outline of the problem and two possible proposals. Looking for
feedback/questions/etc on what people prefer.


Background
---

In Pulp 2, tasks have tags that either provide a task name/description or
info on what resources a task acts on. Tasks also have reserved resources,
which provide a way for tasks to lock a particular resource.

In Pulp 3, we have models TaskTag and ReservedResource[0]. Tasks are
associated with the resources they work on via TaskTag. If a resource is
locked, a ReservedResource record is created in the db and then removed
from the db once the resource is unlocked.


Problem
---

The task tag model doesn't really fit Pulp 3. It's perhaps too generic and
totally unnecessary (see Proposal 1), or it could be redesigned to
accomodate other things (see Proposal 2).

Also, we need to support created resources (e.g. publications) with tasks.
Refactoring task tags might provide an opportunity to do so.


User stories
---

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.


Proposal 1
---

Since tags and reserved resources in Pulp 3 will only store information
about a particular repository (not 100% sure here), it should be possible
to simplify the data model. We could ditch both TaskTag and
ReservedResource models and just have a direct relationship between Tasks
and Repositories (e.g. TaskRepository). This model could also have some
sort of field to indicate whether a particular field is locked (e.g.
is_locked). Unlike ReservedResource, this relationship would be
persisted—only the is_locked field would be updated when a task is done.


Proposal 2
---

We could keep the TaskTag relationship (perhaps even rename it to
TaskResource) and we could add a field to indicate the nature of the
relationship between task and resource (e.g. created, updated, etc). This
field could not only capture what TaskTag is currently used for but also
stuff like created resources (e.g. publications). We could also have a
field to indicate which task resources are locked (e.g. is_locked).

This would be useful for https://pulp.plan.io/issues/3033.


Questions
---

- What proposal do we want to adopt?
- When do we need to address these changes?
- Do we really need to allow users to search tasks by a resource/repo at
all?


[0] https://git.io/vF8iH

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171106/d9fd6b69/attachment.htm>


More information about the Pulp-dev mailing list