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

[Justin Sherrill]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180430/2130e701/attachment.htm>