<div dir="ltr"><div>Here's my next dilemma:</div><div><br></div><div>Should we make the API to GET/PUT these access policies all at one endpoint, or nest them as sub-resources under each viewset they control? I'm outlining the two options below, please reply with your thoughts.<br></div><div><br></div><div><div>Option "nested under each viewset". This would have each access policies live under the viewset it pairs with, e.g. the /pulp/api/v3/remotes/file/file/ would then have a sub-resource /pulp/api/v3/remotes/file/file/access_policy/</div><div>pros: it's simple for users<br></div><div>cons: it's more complicated to develop because we have to try to automatically add this to lots of viewsets. Also it's complicated to see the policies all in one place. Also if there are other sub-resources that may want to use a name like "access_policy" this becomes a problem unless we allow plugin writers to "move" this resource to another area somehow.<br></div><div><br></div></div><div>Option "all at one viewset". This would have all access policies live at /pulp/api/v3/access_policy/ with detail views like /pulp/api/v3/access_policy/:uuid/</div><div>pros: it avoids url conflicts described above. It's easy to implement, and you can see all the policies in one place<br></div><div>cons: it requires users to "find" their access_policy and this could cause user mistakes also...</div><div><br></div><div>What do you think we should do to create the best user experience first-and-foremost, and the best plugin writer experience second-most?</div><div><br></div><div>Thanks!</div><div>Brian</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 14, 2020 at 8:44 AM Tatiana Tereshchenko <<a href="mailto:ttereshc@redhat.com">ttereshc@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">+1 to idea 1 since the URLs seem to me more stable than class paths. We should not change REST API much but potentially can refactor code in some ways.<br><div><br></div><div>One nitpick, maybe the `viewset` field should have a more generic name, since we don't use viewsets exclusively, we also have separate views, e.g. for orphan cleanup or status.</div><div>I don't have good ideas though... `endpoint`? (though it's not a full endpoint), `guarded_view_obj`? `view_object`? `view`? :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 14, 2020 at 2:21 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">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="auto"><div>Pulp 2 users would definitely be familiar with describing policies in terms of urls. The Pulp 3 REST API already uses the pulp_href field as the primary identifier. You should implement idea 1.</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Jul 13, 2020, 5:45 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@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"><div>I need some design input. To store AccessPolicy data in the DB I think we want one Model where each instance is the access policy for a given viewset. I think this would be better than one Model per Viewset which would generate N tables for N viewsets with 1 instance of each which would be very strange and inefficient.</div><div><br></div><div>So let's assume we have a simple definition like the one below. Each instance stores the policy for one viewset.<br></div><div><br></div><div>class AccessPolicy(BaseModel):<br> data = JSONField()</div><div><br></div><div>So what second field can I add to this that would allow me to relate an instance of this model to a viewset. For example the FileRemoteViewset here: <a href="https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116" rel="noreferrer" target="_blank">https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116</a></div><div><br></div><div>Idea 1: Add a viewset = CharField(). Have it store values as URLs, e.g. /pulp/api/v3/remotes/file/file/.</div><div>Idea 2: Add a viewset = CharField(), and have it store values as classpaths, e.g. 'pulp_file.app.viewsets.RemoteFileViewset'.</div><div><br></div><div>I think Idea 1 makes the most sense because that's how our users think of it. I can't think of a good alternative. What do you think makes the most sense? What alternative ideas should we consider?</div><div><br></div><div>If you have feedback please share it. I need to start into something to get it going tomorrow even if it's just Idea 1 for lack of an alternate proposal.<br></div><div><br></div><div>Thanks,</div><div>Brian<br></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" rel="noreferrer" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></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>
</blockquote></div>