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
