[Pulp-dev] Pulp 3.0 REST API gap analysis

Dennis Kliban dkliban at redhat.com
Tue Apr 3 20:00:10 UTC 2018


I updated the MVP doc with the changes[0] we discussed on the list and
during a call we had earlier today. Below are the notes I captured during
the call.

 - remove default remote for a repository feature
 - we are not implementing auto publish feature
 - create an issue for removing auto_publish field from Publishers -
https://pulp.plan.io/issues/3545
 - @asmacdo to create pulp-smash issue for auto distribution test
 - removee old language about repo version add/remove/sync.
 - add 3082 add to sprint
 - remove Sync and Publish section all together
 - remove both red statements about filtering provided by plugins
 - make orphan cleanup text black and add 3442 to the sprint
 - remove filtering by id and state from tasks and issue will be added for
the minimal serializer

After the meeting I also updated the content unit deletion use case. It now
states that the API always returns an error message. If content is not an
orphan, the error provides list of repository versions. If content is an
orphan, the error tells the user to run orphan cleanup.


[0]
https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viable_Product/diff?utf8=%E2%9C%93&version=153&version_from=152&commit=View+differences

On Mon, Apr 2, 2018 at 2:12 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> 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/b
>> lob/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
>>
>>
>
> _______________________________________________
> 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/20180403/de7024b7/attachment.htm>


More information about the Pulp-dev mailing list