[Pulp-dev] Task tagging in Pulp 3

Dennis Kliban dkliban at redhat.com
Thu Nov 9 20:43:59 UTC 2017


On Mon, Nov 6, 2017 at 2:17 PM, David Davis <daviddavis at redhat.com> wrote:

> 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).
>
>
I like proposal number 2.



> 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
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171109/77854835/attachment.htm>


More information about the Pulp-dev mailing list