Re: [Pulp-dev] Plugin relationship to tasks

What still makes me feel most comfortable with the plug-in--centered tasks proposal is that it doesn't try to conceal what actually happens behind the scenes: a plug-in specific task code is fired all the time a new repository version is created, that uses multiple (generic) core Pulp objects to

Re: [Pulp-dev] Plugin relationship to tasks

Here is where I stand: -1 on converting the task status API to task creation API (the original proposal) +1 on adding a hook for plugins to provide repository version validation of content +1 on exploring other ideas to make the v3 API more RESTful (removing the action end points such as 'sync'

Re: [Pulp-dev] Plugin relationship to tasks

I’ve had a chance to think about this some more this week and reread all the emails. I think that the solution of just adding a hook is best. Each solution seems to be imperfect and I think we still want users to interact with objects (remotes, repositories, etc). I’d say I’m +1 on adding a hook

Re: [Pulp-dev] Plugin relationship to tasks

@asmacdo and I talked some and I wanted to share a few of my thoughts on the plugin tasks problem statements. I agree with a problem statement for pulp_docker for example that it would be good for a plugin writer to add custom validation when creating a new repo/version. I thought this idea was

Re: [Pulp-dev] Plugin relationship to tasks

Thanks for the classifications. On Mon, Apr 2, 2018 at 2:37 PM, Dennis Kliban wrote: I think of these actions as 2 new types of resource in Pulp. Unlike > Remotes(Importers currently) and Content, these resources are singletons > that each plugin provides. Since users don't

Re: [Pulp-dev] Plugin relationship to tasks

On Mon, Apr 2, 2018 at 12:41 PM, Austin Macdonald wrote: > I'm concerned that this conversation is too broad. I'm willing to > brainstorm ideas because this is an important topic, but I also hope that > at some point we can come back to the proposal for master/detail tasks.

Re: [Pulp-dev] Plugin relationship to tasks

I'm concerned that this conversation is too broad. I'm willing to brainstorm ideas because this is an important topic, but I also hope that at some point we can come back to the proposal for master/detail tasks. This idea is interesting, because it provides a novel way to connect the plugins to

Re: [Pulp-dev] Plugin relationship to tasks

Here is another idea that would remove the verbs from the REST API and would provide a way to namespace plugin provided tasks. We could add 2 additional resource types for plugin writers to provide: versionaction and publicationaction. These REST resources would only support GET requests. The

Re: [Pulp-dev] Plugin relationship to tasks

Folks, I'd like to summarize where we've gotten so far. Our problem statement is threefold: 1) Content operations have to be routed thru particular plug-ins i.e no repository version can be created without a plug-in involvement, to avoid repository content consistency/correctness issues 2) API

Re: [Pulp-dev] Plugin relationship to tasks

On Wed, Mar 28, 2018 at 12:20 PM, Ina Panova wrote: > I do not think that it's a valid argument to ban the proposal just because > the proposal will bring changes to the existing plugins. Because: > > 1) i think it would be fair to think of other plugins and find a solution >

Re: [Pulp-dev] Plugin relationship to tasks

> > I haven't seen a counterargument to the assertion that it is **incorrect** >> to control repo membership without allowing plugin validation. >> > > We could add hooks for plugins to provide validation for each content > type. The Content model in pulpcore could define >

Re: [Pulp-dev] Plugin relationship to tasks

On Wed, Mar 28, 2018 at 10:21 AM, Austin Macdonald wrote: > > > On Tue, Mar 27, 2018 at 6:11 PM, Brian Bouterse > wrote: > >> In terms of removing POST /api/v3/repositories//versions/ from >> core, I want to bring it back to the MVP language and REST

Re: [Pulp-dev] Plugin relationship to tasks

On Tue, Mar 27, 2018 at 6:11 PM, Brian Bouterse wrote: > In terms of removing POST /api/v3/repositories//versions/ from > core, I want to bring it back to the MVP language and REST which drove the > original design. The MVP has: "As an authenticated user, I can create a new

Re: [Pulp-dev] Plugin relationship to tasks

> > >- /api/v3/repositories//versions/ endpoint does not perform >plugin specific validation which can lead to "broken" repository versions. >- Plugin authors don't have any convention to follow when creating >custom REST API endpoints for creating repository versions. >- As a

Re: [Pulp-dev] Plugin relationship to tasks

On Tue, Mar 27, 2018 at 1:36 PM, Jeremy Audet wrote: > > The current plugin API allows plugin authors to define custom REST API > endpoints that can perform any custom validation needed for the plugin. The > repository version creation REST API provided by pulpcore only

Re: [Pulp-dev] Plugin relationship to tasks

On Tue, Mar 27, 2018 at 12:23 PM, Austin Macdonald wrote: > After some reflection, I think we have been too focused on the small > points (plugin complexity, URL organization, actions vs nouns). They should > be discussed, but we don't have consensus around the primary

Re: [Pulp-dev] Plugin relationship to tasks

On Tue, Mar 27, 2018 at 12:00 AM, Brian Bouterse wrote: > I also want to look at how this will affect our user experience. With this > change, I believe plugin tasks are put at the center of the user experience > and the repositories, content, and versions are moved to the

Re: [Pulp-dev] Plugin relationship to tasks

On Tue, Mar 27, 2018 at 12:02 AM, Austin Macdonald wrote: > > > On Mon, Mar 26, 2018 at 4:43 PM, Dennis Kliban wrote: >> >> On Mon, Mar 26, 2018 at 3:38 PM, Austin Macdonald >> wrote: >>> >>> >>> >>> On Mon, Mar 26, 2018 at 2:30 PM,

Re: [Pulp-dev] Plugin relationship to tasks

On Mon, Mar 26, 2018 at 4:43 PM, Dennis Kliban wrote: > On Mon, Mar 26, 2018 at 3:38 PM, Austin Macdonald > wrote: > >> >> >> On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban >> wrote: >> >>> This proposal does not make the plugin

Re: [Pulp-dev] Plugin relationship to tasks

I also want to look at how this will affect our user experience. With this change, I believe plugin tasks are put at the center of the user experience and the repositories, content, and versions are moved to the background. The user would think about what they can do foremost as a series of tasks.

Re: [Pulp-dev] Plugin relationship to tasks

On Mon, Mar 26, 2018 at 3:38 PM, Austin Macdonald wrote: > > > On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban wrote: > >> This proposal does not make the plugin writer's job any easier. This >> simply changes where the plugin writer is providing validation

Re: [Pulp-dev] Plugin relationship to tasks

Nice choice of music :) On Mon, Mar 26, 2018 at 4:14 PM, Milan Kovacik wrote: > On Mon, Mar 26, 2018 at 9:38 PM, Austin Macdonald > wrote: > > > > > > On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban > wrote: > >> > >> This proposal

Re: [Pulp-dev] Plugin relationship to tasks

On Mon, Mar 26, 2018 at 9:38 PM, Austin Macdonald wrote: > > > On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban wrote: >> >> This proposal does not make the plugin writer's job any easier. This >> simply changes where the plugin writer is providing validation

Re: [Pulp-dev] Plugin relationship to tasks

On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban wrote: > This proposal does not make the plugin writer's job any easier. This > simply changes where the plugin writer is providing validation logic, in a > serializer vs. in a view. > It does make the plugin writer's job easier

Re: [Pulp-dev] Plugin relationship to tasks

To make sure this was feasable, I've created proof of concept PRs for pulpcore and pulp_file. All of the proposed changes are proofed, but not all work is done. For example, sync is implemented, but not publish. - https://github.com/pulp/pulp/pull/3394 -

Re: [Pulp-dev] Plugin relationship to tasks

On Fri, Mar 16, 2018 at 4:55 PM, Milan Kovacik wrote: > > > > On Thu, Mar 15, 2018 at 9:21 PM, Austin Macdonald wrote: >> >> I spoke with daviddavis about this and I would like to narrow the scope a >> bit. This discussion should be limited to endpoints

Re: [Pulp-dev] Plugin relationship to tasks

On Thu, Mar 15, 2018 at 9:21 PM, Austin Macdonald wrote: > I spoke with daviddavis about this and I would like to narrow the scope a > bit. This discussion should be limited to endpoints that deploy tasks. The > possibility for collisions that David pointed out regarding >

Re: [Pulp-dev] Plugin relationship to tasks

I spoke with daviddavis about this and I would like to narrow the scope a bit. This discussion should be limited to endpoints that deploy tasks. The possibility for collisions that David pointed out regarding v3/content// is real, but should be discussed separately because Content objects should

Re: [Pulp-dev] Plugin relationship to tasks

I have an amendment to this proposal. Instead of namespacing just the plugin task routes, I’d propose we namespace all plugin routes. Thus all plugin routes would be namespaced under something like “/api/v3/plugin//“. For example, “/api/v3/content/file/” gets moved to

Re: [Pulp-dev] Plugin relationship to tasks

I reviewed this proposal with Austin, mainly from the perspective of an end user. In my opinion, this proposal is a good one. I find the semantics intuitive and I think they do a good job of adhering to the Richardson Maturity Model

[Pulp-dev] Plugin relationship to tasks

tldr; I am running with an idea that Milan brought up. I think this will create a simpler user experience while providing an obvious pattern to plugin writers. This pattern will offer greater plugin control and flexibility. Problem: Tasks that add/remove content to a repo (which creates