I think, the pulpcore-plugin would at least provide a serializer to derive from, that carries the either-artifact-or-fileupload logic.
On Wed, 4 Sep 2019 11:45:37 -0400 Dennis Kliban <dkli...@redhat.com> wrote: > 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 > >
pgpKs5jC7Nwat.pgp
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
