[Pulp-dev] Plugin relationship to tasks

[Ina Panova]

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
all plugins will be happy with --> so we are back to the generic
correctness problem
2) we are not GA, not even Beta, we are free and eligible to make changes,
no promises made yet.
3) if we bring changes *this* exactly is the time to do because we have
just 2 plugins working with basic functionality :)

W/r to the "Pulp turning into a task running system" ..and yet that's a
system based on distributed task system

I suggest to organize a meeting with an agenda in advance that would list
1) concerns 2) questions
I also think it would be valuable to hear Jeff's feedback.

If the team finds that meeting idea is beneficial with the believe that
after the meeting we will:
1) i am not naive to believe that we would reach consensus but at least we
would move forward
2) we will decrease the frustration level, because face2face conversation
is more profitable, since we do see faces, have social interaction and not
type onto keyboard and stare at the text on the monitor.

then...I will take the action item and schedule the meeting.

Meanwhile we'll have time to chew on Easter eggs and give to the proposal a
deeper, unbiased, full of protein (that helps brain thinking) thought.




--------
Regards,

Ina Panova
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, Mar 28, 2018 at 12:11 AM, Brian Bouterse <bbouters at redhat.com>
wrote:

> In terms of removing POST /api/v3/repositories/<uuid>/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
> version by adding or removing content to the latest version." To
> facilitate that in a generic way, we need a core endpoint to do that, i.e.
> /api/v3/repositories/<uuid>/versions/. My concern is that removing it
> would cause us to not fulfill our use cases without requiring more code
> from some plugin writers. Also in terms of REST philosophy, POSTing to the
> RespotoryVersion resource to create a new RepositoryVersion is the
> traditional url design.
>
> For pulp_ansible, for example, the generic add/remove functionality at
> core endpoint ^ would be meet all of the pulp_ansible user's needs because
> of the way the pulp_ansible content is modelled. So removing this endpoint
> means more work for pulp_ansible developers w.r.t creating repo versions
> and providing tasks and endpoints. I don't see this extra responsibility on
> plugin writers coming with a clear benefit.
>
> One idea I liked in this discussion is to have a documented convention
> that encourages plugin writers to put their viewsets in a namespaced area.
> They still need the ability to put them anywhere due to live API
> goals/requirements so this would only be a convention for those tasks they
> are offering directly to their users.
>
>
>
>
>
> On Tue, Mar 27, 2018 at 5:40 PM, David Davis <daviddavis at redhat.com>
> wrote:
>
>> I like Austin’s task proposal in that the plugin writers can focus on
>> serializers and tasks that can be easily integrated with core. That said, I
>> agree on the counterpoints raise about the new resource endpoints and
>> turning much of pulp into a task running system. So I am a bit mixed on
>> which approach is better.
>>
>> I do think that we should remove POST /api/v3/repositories/<uuid>/versions/
>> from core.
>>
>>
>> David
>>
>> On Tue, Mar 27, 2018 at 3:49 PM, Austin Macdonald <amacdona at redhat.com>
>> wrote:
>>
>>>
>>>>    - /api/v3/repositories/<uuid>/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 result of ^, a user will have a hard time identifying
>>>>    repository version creation APIs in different plugins.
>>>>
>>>>
>>> I agree with these points.
>>>
>>>>
>>>>    -
>>>>
>>>> My first inclination is to disable the ability to POST to
>>>> /api/v3/repositories/<uuid>/versions/ and require users to use the
>>>> plugin specific APIs for creating repository versions. However, I think
>>>> that integrators of build systems that produce a variety of content types
>>>> would have a lot more flexibility if they could use a single generic API
>>>> endpoint to create a repository version independent of the content type.
>>>>
>>>> Let's continue this discussion by answering the following question:
>>>>
>>>>    - Should we disable the ability to POST to
>>>>    /api/v3/repositories/<uuid>/versions/ and require users to always
>>>>    use a plugin specific repository version creation API?
>>>>
>>>> Yes, I think we should disable POST to /api/v3/repositories/<uuid>/ve
>>> rsions/
>>>
>>> Simplifying integration is important, but we should not sacrifice
>>> correctness enforcement.
>>>
>>> _______________________________________________
>>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180328/6569c843/attachment.htm>