This is interesting. Some thoughts:
If adopted, I propose the publication task create the publication and pass to the publisher which would require a change in the plugin API - Publisher.publish(publication). If the publisher fails, I think the publication should be deleted. On 10/19/2017 02:27 PM, Dennis Kliban wrote: > @jortel and I have been discussing[0] how a user should find out what > publication was created after a request > is made to > http://localhost:8000/api/v3/repositories/foo/publishers/example/bar/publish/ > > I propose that we get rid of the above URL from our REST API and add ability > to POST to > http://localhost:8000/api/v3/repositories/foo/publishers/example/bar/publications/ > instead. The response would > be a 201. Each publication would have a task associated with it. Associated how? I hope you are not suggesting adding Publication.task_id (FK). I don't think that would be a good idea. I still like the idea of adding Publication.name as a natural key that can be specified by the user. It can default to the task ID when not specified. This gives users something meaningful to use when selecting a publication for association to a Distribution or when deleting. > > This work would probably be done by whoever picks up issue 3033[1]. > > [0] https://pulp.plan.io/issues/3035 > [1] https://pulp.plan.io/issues/3033 > > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
