<div dir="ltr">> 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.<div><br></div><div>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.</div><div><br></div><div>> auto_publish(bool) - ??? consider adding auto-publish feature to MVP</div><div><br></div><div>I think we agreed to leave auto_publish out of the MVP but forgot to remove it from the doc.</div><div><br></div><div>> As a user, my distribution base paths don't conflict and my create/update is rejected identifying the conflicting distributions</div><div><br></div><div>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.</div><div><br></div><div>> As a user, I want a newly created publication to be automatically served by the content as defined by distributions.</div><div><br></div><div>I think this works.</div><div><br></div><div>> As an authenticated user, I have filters on the Distribution list [3082]</div><div><br></div><div>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.</div><div><br></div><div>> I cannot pass "sync" options. </div><div>> Auto-publish is not included as an importer property.</div><div>> I cannot pass "publish" options.</div><div><br></div><div>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.</div><div><br></div><div>> Content unit deletion needs to be race condition free.</div><div><br></div><div>Covered by <a href="https://pulp.plan.io/issues/3445">https://pulp.plan.io/issues/3445</a></div><div><br></div><div>> As an authenticated user, I can filter Content by repository version information when plugin writers have provided such a filter</div><div>> As an authenticated user, I can filter content on plugin specific attributes when plugin writers have provided such a filter</div><div><br></div><div>This is outstanding work. I think we need someone that can lead this and design out how it should work.</div><div><br></div><div>> 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.</div><div><br></div><div>Not sure I understand this one.</div><div><br></div><div>> As an authenticated user, I can cause an action that cleans up both orphaned content units and orphaned artifacts.</div><div><br></div><div>Covered by <a href="https://pulp.plan.io/issues/3442">https://pulp.plan.io/issues/3442</a>.</div><div><br></div><div> > 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)</div><div>> 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)</div><div><br></div><div>AFAIK, I think these are done.</div><div><br></div><div>> 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.</div><div>> 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.</div><div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Mar 29, 2018 at 7:10 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<br><div><div><div><div><div><div><div><div><div><div><br></div> - fix the language where it is not clear or completely remove it <br></div> - remove features from the MVP document that we don't intend to include in the 3.0 release<br></div></div><br></div>Please reply with feedback about items in red related to the REST API (e.g. As a user, ....). <br><br></div>We should perform a separate gap analysis for the Plugin API. <br><div><br><br><div><div><div><div>[0] <a href="https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viable_Product" target="_blank">https://pulp.plan.io/projects/<wbr>pulp/wiki/Pulp_3_Minimum_<wbr>Viable_Product</a><span class="HOEnZb"><font color="#888888"><br></font></span></div></div></div></div></div><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div> - Dennis <br></div></font></span></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>