> > For the copy case, it's common to copy more than one type, I think, so > probably 'plugin/copy/ types=[]' makes more sense. >
Thanks for this thread. I'm +1 on documenting these general conventions in > the pulpcore-plugin docs for plugin writers. Maybe we could include a > section on URLs so plugin writers could self-assess if they are doing this > or not. > Regarding POST /pulp/api/v3/plugin/action/ types=[] Since this doesn't need to do anything plugin specific (as the type is part of the base content model), my thought was that we would just make it part of core. Individual plugins would then implement endpoints for more specific behaviors. I would hope that each plugin wouldn't need to implement the exact same code to copy units based on their type. My thoughts are based on these use cases (I hope I'm not missing anything): A) copying specific content units by content ID B) copying the contents of entire repositories into other repositories C) copying all units of a type (e.g. RPM) from one repo to another, with no filtering D) copying units of a type (e.g. RPM) from one repo to another if they match some user-provided filters (e.g. name, version) E) copying units of a type (e.g. RPM) from one repo to another if they match some user-provided filters (e.g. name, version), and also copying all their dependencies (using various schemes) Providing a list of types is semi-incompatible with cases D and E (because how would it know how to apply filters to multiple different types at once? it could probably be done, but it would probably be very messy and very plugin-specific code) so I don't know if that is a good basis for an API that all plugins would build on top of. On the other hand, A, B, and C can all be accomplished without any plugin involvement -- core could handle those use cases fine, and plugins would be free to handle D and E however they see fit (although we probably do want some common patterns there). But the common patterns for solving D and E are probably going to be different from what we're discussing at the moment. So I'm not sure if we want to codify POST /pulp/api/v3/plugin/action/ types=[] as our common pattern just yet, at least not without more discussion. On Wed, Jul 31, 2019 at 7:04 AM 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
