[Pulp-dev] Pulp 3 REST API Challenges

Tue Apr 17 22:28:44 UTC 2018

>
> *1.  Core endpoints do not delegate/redirect to plugins.*
>      - POST to /RepositoryVersion/ is removed.
>      - POST to /Publications/  (stays gone)
>      - Plugins provide endpoints for sync and other to create new
> repository versions.
>      - Plugins provide endpoints for creating Publications (publishing).
>

I think this is a good characterization of what would change. I'd like to
add my vision for why option 1 is optimal, leaving out my specific proposal.

   1. *Plugins manage their own data.* All actions
   (sync/publish/add/remove/etc) are controlled by the plugin. Core provides
   tools to make this trivial in the trivial cases, but when a plugin needs to
   do something differently, core stays out of the way. This is the only
   pattern that makes sense when dealing with every possible plugin. We can't
   afford to make assumptions about what every plugin will and won't need.
   2. *Plugin writers follow a single pattern. *Create a model, a viewset,
   and a serializer. If the default behavior doesn't work for you, override
   it. The parts are modular, so you probably only need small changes.
   3. *Every action has a separate endpoint, and complete documentation. *If
   file/sync, file/add/, python/add, are all separate endpoints, they all have
   separate documentation. Each endpoint's also documents its parameters.

> *2. Core delegates behavior to plugins for those endpoints requiring
> plugin participation.*
>     - POST to /RepositoryVersion/ is the only way to create a repository
> version.
>     - POST to /Publications/  is the only way to create a Publication
> (publish).
>     - The POST parameters or body includes enough information so that core
> can select a plugin.
>     - Either the entire POST is passed along to the plugin, *or* the
> plugin implements an API that's used by
>       core for pre-defined participation.
>

Restricting all repository version creation to a single endpoint is cool,
but Option 2 means that pulpcore accepts requests that involve plugins.
This begs the question, how does core involve plugins? This is such an
important question that it is difficult to discuss this idea at all outside
of a specific implementation.

There is one thing that really bothers me about any possible implementation
of Option 2, the documentation. If we combine various behaviors into a
single endpoint, then how do we clearly document each of them?
The plan for Option 2 as I understand it would not document (in the docs)
the specifics for how to sync/publish etc. Even if that problem is
addressed somehow, we still have an awkward hierarchy. As you can see
below, because plugins are primary in option 1, the action docs are
separated by plugin. This makes sense, because each workflow involves only
one plugin.

   - Option 1
      - As a plugin x user
         - I can sync.
         - I can add/remove
      - As a plugin y user
         - I can sync.
         - I can add/remove.
      - As a plugin z user
         - I can sync
         - I can add-complex-depsolving

   - Option 2
      -  As a user I can create a new RepositoryVersion
         - by plugin x sync
         - by plugin x add/remove
         - by plugin y sync
         - by plugin y add/remove
         - by plugin z sync
         - by plugin z add-complex-depsolving

There have been proposals on how both #1 and #2 can be achieved. I'm
>
wondering if we can even agree on one of these two approaches.
>

It would be very convenient if we agreed on an approach separately from
implementation, but I don't think it is possible. Each strategy has obvious
pros but the cons are tucked away in the implementation details.

>
>>
>>> A File repository version cannot be properly published if it contains 2
>>>> FileContent units that both have the same relative path. The publisher has
>>>> to decide which FileContent to publish at the relative path. That decision
>>>> cannot be made intelligently by the publisher. The decision on which
>>>> content unit to include in the repository version rests with the user that
>>>> is creating the repository version. When a user tries to create a
>>>> repository version with a FileContent that has the same relative path as
>>>> another FileContent that was added previously, Pulp needs to inform the
>>>> user that there is a conflict (and not create the repositiory version).
>>>> This validation can only be provided by the File plugin.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> We would like to get feedback on these issues being sound and worth
>>>>>>> resolving before we resume particular solution discussion[1].
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Austin, Dennis, and Milan
>>>>>>>
>>>>>>> [1] https://www.redhat.com/archives/pulp-dev/2018-March/msg00066
>>>>>>> .html
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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 listPulp-dev at redhat.comhttps://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
>>>
>>>
>>
>> _______________________________________________
>> 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/20180417/490a48cc/attachment.htm>