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 <aus...@redhat.com> wrote: > > > On Fri, Mar 30, 2018 at 9:23 AM, David Davis <davidda...@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 <davidda...@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 <dkli...@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@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
