<div dir="ltr">The solution proposed in #3541 looks good for validation purposes.<div>My understanding of the problem is that a plugin needs to apply some logic and decide which content to keep and which content to remove at repo version creation time and perform these changes.</div><div>Examples:</div><div> - add to a repo version only RPMs signed with a specific key</div><div> - removal of the moduled content should automagically remove related RPMs from a repo version.</div><div><br></div><div>In theory, for the examples above, if we have validation only, user can be forced to prepare perfect add/remove requests, however I think it won't be a good user experience.</div><div><br></div><div>Can it be done in the same way as the suggestion for validation? Just if it makes sense for plugin to "fix" repo version itself, they will do it, otherwise validation error can be raised. What do you think?</div><div><br></div><div>Tanya</div><div><div></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 8, 2019 at 4:46 PM Dennis Kliban <<a href="mailto:dkliban@redhat.com">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The plan outlined in 3541 solves the problem in a way that gives plugin writers a lot of control. +1 to implementing it.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2019 at 12:23 PM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We have a blocker for Pulp 3.0 GA[0] that we need to address soon in order to let plugins leverage it in their upcoming GA releases. It involves allowing plugin writers to validate content in a repo version. It's somewhat related to validating uniqueness in a repo version[1] except there are cases other than uniqueness that plugins might want to handle. One example might be a case where we want to prevent a user from adding a docker tag that points to a manifest outside a repo from getting added to the repo. I'm not sure if this is an actual example but it gives you an idea that there might be other non-unique validation plugin writers might want to add.<div><br></div><div>Brian proposed a solution on 3541 that I think solves the problem[2]. I was hoping to maybe get some feedback on it so we could proceed by October 9. </div><div><div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/3541" target="_blank">https://pulp.plan.io/issues/3541</a></div><div>[1] <a href="https://pulp.plan.io/issues/5008" target="_blank">https://pulp.plan.io/issues/5008</a></div><div>[2] <a href="https://pulp.plan.io/issues/3541" target="_blank">https://pulp.plan.io/issues/3541</a></div><div><br></div><div>David<br></div></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>