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

Mon Apr 30 15:13:44 UTC 2018

+1 to fixing whatever the issue that prevents the built bindings from
working. If David's proposal does that then +1.

I want to share an opinion on continuing with the use of urls (in addition
perhaps to ids) and not supporting rerooting a Pulp deployment. Using hrefs
is valuable in the response and the requests because the client doesn't
have to understand what resource type they should use for a given object
being referenced. In practice you can open the next resource without any
url parsing/forming. In terms of rerooting an application, it will break
clients. It reminds me of this W3C page I read which suggests that great
URIs are expected to never change: https://www.w3.org/Provider/Style/URI

I hope we can fix the bindings asap. Sorry they aren't working. Thank you
for reporting this via the list.

On Mon, Apr 30, 2018 at 10:24 AM, Justin Sherrill <jsherril at redhat.com>
wrote:

>
>
> On 04/30/2018 10: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).
>
> 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.
>
>
> It matters if you are a client and are fetching stored hrefs.
>
> Justin
>
>
>
>
> 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 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/5cc62921/attachment.htm>