[Pulp-dev] Pulp 3.0 REST API gap analysis

David Davis daviddavis at redhat.com
Fri Mar 30 13:23:24 UTC 2018


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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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 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.
>
> > 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.
>
> > 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.
>
>
>
> 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_Viable_Product
>>
>>  - Dennis
>>
>> _______________________________________________
>> 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/20180330/76364ea2/attachment.htm>


More information about the Pulp-dev mailing list