On Wed, Sep 4, 2019 at 11:12 AM Brian Bouterse <bmbou...@redhat.com> wrote:
> I want to bring back a variation on upload needs that has come out of > various discussions w/ several plugin developers. I wrote it up here in > more detail and I'll sumarize below: https://pulp.plan.io/issues/5403 > > 1. Make all uploads of a specific content type live at POST > /pulp/api/v3/content/<plugin_name>/<content_name>/ > +1 ... However, what are we going to provide in the plugin template for this? Right now we provide a ModelViewSet. I am picturing this would be a default implementation from pulpcore-plugin that would not extract any information from the file, but would simply create an instance of the *Content model and a ContentArtifact with a relative path. Is that what you had in mind? > 2. Have it accept either binary data (to create an Artifact from before > the Content unit) OR a reference to an existing Artifact (allowing the > chunked upload API to be used) but not both. > > What do you think? > > > > On Wed, Aug 14, 2019 at 12:32 PM Ina Panova <ipan...@redhat.com> wrote: > >> There have been ongoing couple of more discussions offline regarding >> copy/remove and it kinda boiled down to: >> >> v3/<plugin-type>/<content-type>/action/ which will allow filtering >> v3/<plugin-type>/<genericaction>/ will not allow filtering >> >> -------- >> Regards, >> >> Ina Panova >> Senior Software Engineer| Pulp| Red Hat Inc. >> >> "Do not go where the path may lead, >> go instead where there is no path and leave a trail." >> >> >> On Thu, Aug 1, 2019 at 8:31 PM Daniel Alley <dal...@redhat.com> wrote: >> >>> Ina and I discussed this earlier today and she made good points -- she >>> pointed out that what I suggested wouldn't work for content types that have >>> relations on non-content models, as several content types in the Docker and >>> Python plugins do. So, I no longer think it's a good idea to have an >>> endpoint with "types=[]" in core. >>> >>> However, I still think that the "types=[]" pattern doesn't compose very >>> well with other features like filtering so I'm not sure if we want to adopt >>> that yet. >>> >>> On Thu, Aug 1, 2019 at 8:54 AM Ina Panova <ipan...@redhat.com> wrote: >>> >>>> For the one shot upload usecase I tend to lean towards >>>> /v3/<plugin>/<content_type>/upload/ and for content_types that require >>>> special treatment we can define separate endpoints. >>>> If talking about modulemd or modulemd_defaults, it could be >>>> /v3/rpm/modules/upload/. >>>> >>>> -------- >>>> Regards, >>>> >>>> Ina Panova >>>> Senior Software Engineer| Pulp| Red Hat Inc. >>>> >>>> "Do not go where the path may lead, >>>> go instead where there is no path and leave a trail." >>>> >>>> >>>> On Wed, Jul 31, 2019 at 1:04 PM Tatiana Tereshchenko < >>>> ttere...@redhat.com> wrote: >>>> >>>>> If the goal is to make endpoints unified across all actions, then I >>>>> think we can only do >>>>> POST /pulp/api/v3//plugin/action/ types=[] >>>>> >>>>> Having plugin/content_type/upload would be nice, however I'm not sure >>>>> if it covers enough use cases. >>>>> E.g. For pulp_rpm, it makes sense for packages or advisories to have >>>>> a dedicated endpoint each, however it doesn't make much sense for modulemd >>>>> or modulemd_defaults, because usually they are in the same file and >>>>> uploaded in bulk (maybe a separate endpoint is needed for this case). >>>>> >>>>> For the copy case, it's common to copy more than one type, I think, so >>>>> probably 'plugin/copy/ types=[]' makes more sense. >>>>> >>>>> It would be great to here from more people and other plugins. >>>>> >>>>> >>>>> >>>>> On Mon, Jul 29, 2019 at 5:46 PM Pavel Picka <ppi...@redhat.com> wrote: >>>>> >>>>>> +1 for discuss this to keep some standard as I have already opened >>>>>> PRs for rpm modulemd[-defaults]. >>>>>> I like idea of /upload in the end. >>>>>> But also think it can work without as it will be differ by POST/GET >>>>>> methods. >>>>>> >>>>>> On Mon, Jul 29, 2019 at 4:49 PM Dana Walker <dawal...@redhat.com> >>>>>> wrote: >>>>>> >>>>>>> Just to provide an added data point, I'll be merging the one-shot PR >>>>>>> for pulp_python soon and it currently uses /api/v3/python/upload/ >>>>>>> >>>>>>> I wanted to keep it simple as well, and so would be happy to change >>>>>>> it for consistency based on whatever we decide. >>>>>>> >>>>>>> --Dana >>>>>>> >>>>>>> Dana Walker >>>>>>> >>>>>>> She / Her / Hers >>>>>>> >>>>>>> Software Engineer, Pulp Project >>>>>>> >>>>>>> Red Hat <https://www.redhat.com> >>>>>>> >>>>>>> dawal...@redhat.com >>>>>>> <https://www.redhat.com> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jul 29, 2019 at 10:42 AM Ina Panova <ipan...@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> As of today, plugins have the freedom to define whichever endpoints >>>>>>>> they want ( to some extent). >>>>>>>> This leads to the question - shall we namespace one-shot upload and >>>>>>>> copy endpoints for some consistency? >>>>>>>> >>>>>>>> POST /api/v3/content/rpm/packages/upload/ >>>>>>>> POST /api/v3/content/rpm/packages/copy/ >>>>>>>> >>>>>>>> or >>>>>>>> >>>>>>>> POST /api/v3/content/rpm/upload/ type =package >>>>>>>> POST /api/v3/content/rpm/copy/ type = [package, modulemd] >>>>>>>> >>>>>>>> I wanted to bring this up, before it diverges a lot. For the >>>>>>>> record, I have checked only RPM plugin, I am not aware of the state of >>>>>>>> the >>>>>>>> other plugins. >>>>>>>> Right now we have an active endpoint for one-shot upload of rpm >>>>>>>> package: >>>>>>>> POST /api/v3/content/rpm/upload/ >>>>>>>> >>>>>>>> And there is PR for one-shot upload of modulemd-defaults: >>>>>>>> POST /api/v3/content/rpm/modulemd-defaults/ >>>>>>>> >>>>>>>> For rpm copy we have POST /api/v3/content/rpm/copy/ types=[] >>>>>>>> >>>>>>>> We are starting some work on docker recursive copy, so it would be >>>>>>>> helpful to reach some agreement before going further that path. >>>>>>>> >>>>>>>> Thank you! >>>>>>>> -------- >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ina Panova >>>>>>>> Senior Software Engineer| Pulp| Red Hat Inc. >>>>>>>> >>>>>>>> "Do not go where the path may lead, >>>>>>>> go instead where there is no path and leave a trail." >>>>>>>> _______________________________________________ >>>>>>>> Pulp-dev mailing list >>>>>>>> Pulp-dev@redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> Pulp-dev@redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Pavel Picka >>>>>> Red Hat >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> Pulp-dev@redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev