[Pulp-dev] Pulp 3.0 REST API gap analysis

Brian Bouterse bbouters at redhat.com
Mon Apr 2 18:12:09 UTC 2018


I'm +1 to everything said here. I can clarify one thing regarding:

* As a user, I have docs that when a new RepositoryVersion is created,
add_many and remove_many are performed before any Plugin code is executed.

This is from before when the sync task was a core provided task. Then the
design changes so tasks are all created by plugins and this was never
updated. We should remove ^ line since Pulp doesn't allow the combination
of add_many and remove_many w/ sync.

With all this agreement, editing the MVP as one edit and sending the diff
link would be a transparent way to move forward the MVP doc changes.

On Mon, Apr 2, 2018 at 1:58 PM, Austin Macdonald <austin at redhat.com> wrote:

>
>
> On Fri, Mar 30, 2018 at 9:23 AM, David Davis <daviddavis at redhat.com>
> wrote:
>
>> Sorry, I think the Importer and Publisher subclass user stories probably
>> need to be updated to more accurately reflect how plugin writers implement
>> syncing and publishing.
>>
>>
>> David
>>
>> On Fri, Mar 30, 2018 at 9:20 AM, David Davis <daviddavis at redhat.com>
>> wrote:
>>
>>> > As an authenticated user, I can define a default remote on a repo via
>>> href to be used whenever a new repo version is created.
>>>
>>> I kind of have a proposal around this and I think we should ask
>>> Katello/users what they need. I’d propose leaving this off the MVP for now.
>>>
>>
> +1, lets remove. Some optimization around this would be nice, but is not
> "minimum".
>
>
>>
>>>
>> > auto_publish(bool) - ??? consider adding auto-publish feature to MVP
>>>
>>> I think we agreed to leave auto_publish out of the MVP but forgot to
>>> remove it from the doc.
>>>
>>
> If we do remove it, we should remove the field from the model/serializer
> also.
>
>
>>
>>> > As a user, my distribution base paths don't conflict and my
>>> create/update is rejected identifying the conflicting distributions
>>>
>>> I’ve been working on this on my own time outside of work since it’s not
>>> on the sprint. I think I’ll have this soon.
>>>
>>> > As a user, I want a newly created publication to be automatically
>>> served by the content as defined by distributions.
>>>
>>> I think this works.
>>>
>>
> Yeah I think so too. https://github.com/pulp/pulp/blob/3.0-dev/pulpcore/
> pulpcore/app/models/publication.py#L107-L112
>
>>
>>> > As an authenticated user, I have filters on the Distribution
>>> list [3082]
>>>
>>> I raised this issue at the sprint planning before the beta feature
>>> freeze but we agreed not to address it/add it to the sprint. I can’t
>>> remember why though.
>>>
>>> > I cannot pass "sync" options.
>>> > Auto-publish is not included as an importer property.
>>> > I cannot pass "publish" options.
>>>
>>> We don’t validate extraneous parameters. These might be just to
>>> emphasize that we’re not supporting this for now. I wouldn’t mind removing
>>> them from the MVP.
>>>
>>> +1, let's remove.
>
> > Content unit deletion needs to be race condition free.
>>>
>>> Covered by https://pulp.plan.io/issues/3445
>>>
>>
>>> > As an authenticated user, I can filter Content by repository version
>>> information when plugin writers have provided such a filter
>>>
>> > As an authenticated user, I can filter content on plugin specific
>>> attributes when plugin writers have provided such a filter
>>>
>>
> This is a plugin feature, we should remove from the MVP. The plugin
> defines a content viewset, which specifies its own filters.
>
>>
>>> This is outstanding work. I think we need someone that can lead this and
>>> design out how it should work.
>>>
>>
>>> > As a user, I have docs that when a new RepositoryVersion is created,
>>> add_many and remove_many are performed before any Plugin code is executed.
>>>
>>> Not sure I understand this one.
>>>
>>
> This is the "docs" solution to https://pulp.plan.io/issues/3541
>
>
>>
>>> > As an authenticated user, I can cause an action that cleans up both
>>> orphaned content units and orphaned artifacts.
>>>
>>> Covered by https://pulp.plan.io/issues/3442.
>>>
>>>  > As a plugin writer, I can provide a subclassed Importer. The
>>> importer's responsibility is to synchronize the content of a Pulp
>>> repository with the content of a remote repository. (a circular import
>>> problem needs to be discussed and may cause this to change)
>>> > As a plugin writer, I can provide a subclassed Publisher. The
>>> publisher's responsibility is to publish content. (a circular import
>>> problem needs to be discussed and may cause this to change)
>>>
>>> AFAIK, I think these are done.
>>>
>>
> These lines should be:
> As a plugin writer, I can provide a subclassed Remote. The Remote's
> responsibility is to store all of the information necessary to communicate
> with an external source of content. (The rest is handled by the "sync"
> task, not the remote)
> As a plugin writer, I can provide a subclassed Publisher.
>
>
>>
>>> > As a plugin writer, I expect units that are missing from the remote
>>> repository to not be created in Pulp when using the immediate download
>>> policy.
>>> > As a plugin writer, I expect units that are missing from the remote
>>> repository to be created in Pulp when using background or on_demand
>>> download policies.
>>>
>>> These seem backwards to me. If we’re not doing lazy sync in the MVP (and
>>> I don’t think we are) then we should probably just remove them.
>>>
>>> +1, lets remove this this from the MVP
>
>>
>>>
>>> David
>>>
>>> On Thu, Mar 29, 2018 at 7:10 PM, Dennis Kliban <dkliban at redhat.com>
>>> wrote:
>>>
>>>> Kersom and I spent the afternoon going over the REST API features
>>>> described in the MVP[0] document. We discovered that a few features are
>>>> poorly worded and a few features have not been implemented. All these items
>>>> are now written in red. We need to do 2 things:
>>>>
>>>>     - fix the language where it is not clear or completely remove it
>>>>     - remove features from the MVP document that we don't intend to
>>>> include in the 3.0 release
>>>>
>>>> Please reply with feedback about items in red related to the REST API
>>>> (e.g. As a user, ....).
>>>>
>>>> We should perform a separate gap analysis for the Plugin API.
>>>>
>>>>
>>>> [0] https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl
>>>> e_Product
>>>>
>>>>  - Dennis
>>>>
>>>> _______________________________________________
>>>> 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/20180402/20e7dc06/attachment.htm>


More information about the Pulp-dev mailing list