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

Bryan Kearney bkearney at redhat.com
Mon Apr 30 15:22:11 UTC 2018


Is that true in practice? Most uses I see of APIs are around language
bindings where the url is not used as oftern.

-- bk

On 04/30/2018 11:13 AM, Brian Bouterse wrote:
> +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
> <mailto: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 <mailto: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
>>>         <https://www.redhat.com/archives/pulp-dev/2018-January/msg00004.html>
>>>         [1] https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54
>>>         <https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb247aba8bf5b45633eba414b79/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 <mailto: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 <mailto:jsherril at redhat.com>> wrote:
>>>
>>>                 Hi All!
>>>
>>>                 I started playing around with pulp 3 and generated
>>>                 bindings via https://pulp.plan.io/issues/3580
>>>                 <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/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/
>>>                 <http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/>",
>>>                     "_latest_version_href": null,
>>>                     "_versions_href":
>>>                 "http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/versions/
>>>                 <http://localhost:8000/pulp/api/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 <mailto:Pulp-dev at redhat.com>
>>>                 https://www.redhat.com/mailman/listinfo/pulp-dev
>>>                 <https://www.redhat.com/mailman/listinfo/pulp-dev>
>>>
>>>
>>>
>>>             _______________________________________________
>>>             Pulp-dev mailing list
>>>             Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>>>             https://www.redhat.com/mailman/listinfo/pulp-dev
>>>             <https://www.redhat.com/mailman/listinfo/pulp-dev>
>>>
>>>
>>
>>
> 
> 
>     _______________________________________________
>     Pulp-dev mailing list
>     Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>     https://www.redhat.com/mailman/listinfo/pulp-dev
>     <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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180430/2d4d3d41/attachment.sig>


More information about the Pulp-dev mailing list