[Pulp-dev] pulp3: Task Resource proposal
daviddavis at redhat.com
Thu Jun 29 19:16:58 UTC 2017
I've been working on supporting tags in Pulp 3 and have gotten some
feedback from various other developers. I'd like to open up the discussion
though to a broader audience and see if anyone has any feedback.
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).
For resource tags, these will be replaced with Task Resources. Like
resource tags, these will be a one-to-many relationship to tasks (ie a task
will have many task resources). These Task Resources then have a one-to-one
generic relation to any object in Pulp that a task can act on.
name - varchar
id - uuid
task_id - uuid (foreign key to a task)
content_type - varchar (e.g. "Repository")
object_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, I'm imagining that there won't be a separate API for
Task Resources. Instead, task resource information will be returned along
with tasks in a list field such as "resources." This presents a bit of a
problem though: each resource will have different data depending on the
type of resource (repo, publisher, etc). Alternatively, we could return
a homogeneous list of hashes with fields like type (Publisher/Repository,
etc), id, and href. However, I think this is less useful to users.
For filtering, I think it would be possible to filter on content_type and
object_id in Task Resource but I think this would be inconvenient for
users. I think it would be easier if we define some shortcuts (e.g.
repository_id, publisher_id, etc) that users can use to filter on. I'm
imagining one such id filter for every possible content_type.
Thoughts on this design?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev