[Pulp-dev] Pulp api seemingly incompatible with generated bindings

Mon Apr 30 20:08:13 UTC 2018

@asmacdo, checking in on the why is great. I want to try to articulate the
benefits as I see them. Other perspectives and discussion are welcome.

The design of using URLs for referring things is a design whose goal is to
minimize complexity as the # of resources grows. The Internet is a useful
analogy here. When someone wants to tell me how to find something on
Instagram, if the article's name is 'cat_pic432642' and that's all I know,
I'm going to have a hard time figuring out the actual URL to ask
Instagram's servers for, e.g. /thepostsarehere/cat_pic432642. Even if I did
know how Instram's url space was laid out, I have to think about it
different from all other web services I interact with; now they're all
different. This is the power of the URL itself. All clients and all servers
can use the uniform resource locator to refer to things. I think this was
the main contribution from Tim Berners-Lee that allowed him to implement
HTTP which has URIs at its heart.

To bring it back to Pulp, what we have in Pulp avoids complexity the same
way. The nice part is that we can generically process the input from the
client, i.e. a URL, into the model object. To start accepting IDs instead
of URLs then the server code now needs to know the classpath (hard coded)
for every argument received. This is the complexity we get to avoid via
URIs versus IDs.

On Mon, Apr 30, 2018 at 3:35 PM, Austin Macdonald <austin at redhat.com> wrote:

> I'm not sure how we should handle this, but I have a value question.
>
> Our CLI and Bindings will be autogenerated, so they will always have the
> full functionality of the REST API. Is there a reason our users would use
> the REST API directly? If the REST API is only used through the
> bindings/cli, what is the benefit of being HATEOAS compliant?
>
>
> On Mon, Apr 30, 2018 at 3:21 PM, Jeff Ortel <jortel at redhat.com> wrote:
>
>>
>>
>> On 04/30/2018 09:05 AM, David Davis wrote:
>>
>> So what I’d probably propose is exposing the UUIDs in the response and
>> then extending HyperlinkedRelatedFields to accept UUID or href. Then
>> third parties like Katello could store and just use UUIDs (and not worry
>> about hrefs).
>>
>>
>> +1 to exposing/supporting both the PKs and hrefs.  Btw: We should be
>> talking in terms of resource PKs (primary keys) or IDs instead of UUIDs for
>> clarity.
>>
>>
>>
>> Regarding hrefs though, hostname and port don’t matter. The app just
>> looks at the relative path. It looks like changing the deployment path
>> causes problems though.
>>
>>
>> David
>>
>> On Mon, Apr 30, 2018 at 9:58 AM, Justin Sherrill <jsherril at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On 04/27/2018 07:18 PM, David Davis wrote:
>>>
>>> I’m not sure how returning UUIDs in our responses helps Katello. In our
>>> previous conversation, it was concluded that Katello should use the
>>> hrefs[0]. Why expose UUIDs if Katello is not going to store them?
>>>
>>>
>>> And thats fine, but bindings are pointless at that point, so pulp
>>> shouldn't really advertise them as a feature.   This seemed to have been
>>> 'talked up' quite a bit as a feature, but is completely unusable.
>>>
>>>
>>> Katello could store/use UUIDs but then it's going to run into problems
>>> when dealing with parameters that are hrefs (such as repository_version for
>>> publishing[1]).
>>>
>>> [0] https://www.redhat.com/archives/pulp-dev/2018-January/msg00004.html
>>> [1] https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb24
>>> 7aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54
>>>
>>>
>>> Could you explain a bit about this?
>>>
>>> In order to use pulp 3 then, i'd guess we would either need to:
>>>
>>> 1) store ALL hrefs about all objects
>>> 2) fetch an object before we can do anything with it
>>>
>>> Or am i missing an option 3?
>>>
>>> On a side note, the href's seem to include hostname/port/deployment
>>> path.  This seems incompatible with things like hostname changes.  We can
>>> fairly easily just chomp off only the path, but if i were a user and had
>>> stored all these hrefs, i would be very unhappy if i had all the full
>>> href's stored.
>>>
>>> Justin
>>>
>>>
>>>
>>>
>>> David
>>>
>>> On Fri, Apr 27, 2018 at 4:29 PM, Dennis Kliban <dkliban at redhat.com>
>>> wrote:
>>>
>>>> I can't remember why we decided to remove UUID from the responses. It
>>>> sounds like we should add them back.
>>>>
>>>> On Fri, Apr 27, 2018 at 12:26 PM, Justin Sherrill <jsherril at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi All!
>>>>>
>>>>> I started playing around with pulp 3 and generated bindings via
>>>>> https://pulp.plan.io/issues/3580 and it results somewhat in what you
>>>>> would expect.  Here's an example:
>>>>>
>>>>>     # @param id A UUID string identifying this repository.
>>>>>     # @param [Hash] opts the optional parameters
>>>>>     # @return [Repository]
>>>>>     def repositories_read(id, opts = {})
>>>>>       data, _status_code, _headers = repositories_read_with_http_info(id,
>>>>> opts)
>>>>>       return data
>>>>>     end
>>>>>
>>>>>
>>>>> Notice that the UUID is to be passed in.  When creating a repository,
>>>>> i only get the _href:
>>>>>
>>>>> {
>>>>>     "_href": "http://localhost:8000/pulp/ap
>>>>> i/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/",
>>>>>     "_latest_version_href": null,
>>>>>     "_versions_href": "http://localhost:8000/pulp/ap
>>>>> i/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/versions/",
>>>>>     "created": "2018-04-27T15:26:03.546956Z",
>>>>>     "description": "",
>>>>>     "name": "test",
>>>>>     "notes": {}
>>>>> }
>>>>>
>>>>> Meaning, there's really no way to use this specific binding with the
>>>>> return format for pulp.   I imagine most binding generation would be
>>>>> expecting the user to know the ID of the objects and not work off of
>>>>> _hrefs.  Any reason to not include the IDs in the response?
>>>>>
>>>>> Justin
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Pulp-dev mailing listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>>
>> _______________________________________________
>> 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/20180430/68ca4bf1/attachment.htm>