[Pulp-dev] [pulp 3] proposed change to publishing REST api

[Brian Bouterse]

Agreed on publications not having 'natural key's for the same reasons you
outline.

The tasking system has a progress reporting feature to report progress, but
it's not a place for general reporting. The reasoning is outlined in the
notes from @ichimonji10 and myself earlier.

>From a high level, we want a relationship between objects produced by tasks
and the tasks that produce them. I think this motivates having
Publication.task (FK to Task). With this design the user would

1. POST to http://localhost:8000/api/v3/repositories/foo/publishers/example/bar/publications/
with {'publisher': 'http://path/to/my/publisher'}
2. The user receives a 201 with Publication.task containing the url to
monitor by.
3. The user monitors the publication via the URL.

We mostly avoid this problem with sync because the updates aren't about
objects created it's more about "what is going on" reporting.

-Brian


On Mon, Oct 23, 2017 at 2:45 PM, Michael Hrivnak <mhrivnak at redhat.com>
wrote:

>
>
> On Mon, Oct 23, 2017 at 11:06 AM, Jeff Ortel <jortel at redhat.com> wrote:
>
>>
>> On 10/23/2017 09:55 AM, Michael Hrivnak wrote:
>> >
>> > A task status should not include an exhaustive list of every resource
>> created. For example, a publish task
>> > should not include a reference to every metadata artifact it made. It
>> would be sufficient to include a
>> > reference to the publication, the task's primary output, which then can
>> be used to reference subordinate
>> > resources.
>> >
>> > On a task status representation, this could be included in a field
>> called "created_resources", "output",
>> > "return_value", or similar.
>>
>> Tasks (status) are a transient mechanism used to accomplish work and
>> should not be used to track resources
>> created.  Once the task has completed, the user should be free to forget
>> the task ID and be able to use
>> natural keys to find and inspect resources that got created/updated.
>>
>
> I'm also not sure what natural key a publication will be able to reliably
> have. If I publish the same repo three times, how do I know which
> publication resulted from each task? Or when a repo version is created by a
> sync, how would an end user know which version was created by the task they
> were monitoring?
>

> Just as a 201 response should include a link to the resource that was
> created, a 202 should include a link to a resource that can monitor the
> status of the request to create something. Why would that status monitor
> not upon completion include a link to the resource that got created? It's
> fulfilling the same end goal that could otherwise be achieved from a 201
> response, but with an asynchronous part of the workflow.
>
> --
>
> Michael Hrivnak
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
> _______________________________________________
> 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/20171023/50095da1/attachment.htm>