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

[David Davis]

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.


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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180430/36101b9f/attachment.htm>