[Pulp-dev] Namespacing one shot upload and copy endpoints

Matthias Dellweg dellweg at atix.de
Wed Sep 4 19:12:16 UTC 2019


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 <dkliban at redhat.com> wrote:

> On Wed, Sep 4, 2019 at 11:12 AM Brian Bouterse <bmbouter at 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 <ipanova at 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 <dalley at 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 <ipanova at 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 <  
> >>>> ttereshc at 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 <ppicka at 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
> >>>>>> <dawalker at 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>
> >>>>>>>
> >>>>>>> dawalker at redhat.com
> >>>>>>> <https://www.redhat.com>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Jul 29, 2019 at 10:42 AM Ina Panova
> >>>>>>> <ipanova at 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 at redhat.com
> >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
> >>>>>>>>  
> >>>>>>> _______________________________________________
> >>>>>>> Pulp-dev mailing list
> >>>>>>> Pulp-dev at redhat.com
> >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
> >>>>>>>  
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Pavel Picka
> >>>>>> Red Hat
> >>>>>> _______________________________________________
> >>>>>> Pulp-dev mailing list
> >>>>>> Pulp-dev at redhat.com
> >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
> >>>>>>  
> >>>>> _______________________________________________
> >>>>> Pulp-dev mailing list
> >>>>> Pulp-dev at redhat.com
> >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
> >>>>>  
> >>>> _______________________________________________
> >>>> Pulp-dev mailing list
> >>>> Pulp-dev at redhat.com
> >>>> https://www.redhat.com/mailman/listinfo/pulp-dev
> >>>>  
> >>> _______________________________________________  
> >> Pulp-dev mailing list
> >> Pulp-dev at redhat.com
> >> https://www.redhat.com/mailman/listinfo/pulp-dev
> >>  
> > _______________________________________________
> > Pulp-dev mailing list
> > Pulp-dev at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-dev
> >  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190904/3d8af00a/attachment.sig>


More information about the Pulp-dev mailing list