[Pulp-dev] Plugin relationship to tasks

Wed Mar 28 19:38:17 UTC 2018

On Wed, Mar 28, 2018 at 12:20 PM, Ina Panova <ipanova at redhat.com> 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
> 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
>

Pulp may rely on a tasking system to get work done, but we don't want users
thinking of it as a tasking system. We want our users to think of Pulp as a
repository management 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.
>
>
I am against having a meeting to discuss this. The discussion on the list
has gotten traction and I'd like it to continue on here.

>
>
>
> --------
> 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
>>
>>
>
> _______________________________________________
> 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/aafc6c4e/attachment.htm>