[Pulp-dev] AccessPolicy Model Advice ... input needed

[Tatiana Tereshchenko]

+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.

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.
I don't have good ideas though... `endpoint`? (though it's not a full
endpoint), `guarded_view_obj`? `view_object`? `view`? :)

On Tue, Jul 14, 2020 at 2:21 AM Dennis Kliban <dkliban at redhat.com> wrote:

> 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.
>
> On Mon, Jul 13, 2020, 5:45 PM Brian Bouterse <bmbouter at redhat.com> wrote:
>
>> 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.
>>
>> So let's assume we have a simple definition like the one below. Each
>> instance stores the policy for one viewset.
>>
>> class AccessPolicy(BaseModel):
>>     data = JSONField()
>>
>> 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:
>> https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116
>>
>> Idea 1: Add a viewset = CharField(). Have it store values as URLs, e.g.
>> /pulp/api/v3/remotes/file/file/.
>> Idea 2: Add a viewset = CharField(), and have it store values as
>> classpaths, e.g. 'pulp_file.app.viewsets.RemoteFileViewset'.
>>
>> 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?
>>
>> 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.
>>
>> Thanks,
>> Brian
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> _______________________________________________
> 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/20200714/5cafe121/attachment.htm>