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

Mon Apr 30 21:59:39 UTC 2018

I went ahead and exposed an ‘id’ field[0] ahead of the beta Wednesday which
should unblock Katello.

I called it ‘id’ for now but am interested in getting feedback on the name
of the field. There was also the suggestion of ‘pk’.

[0] https://github.com/pulp/pulp/pull/3481

David

On Mon, Apr 30, 2018 at 4:45 PM, Dennis Kliban <dkliban at redhat.com> wrote:

> In order to unblock Justin, I have created a story[0] to expose the PKs.
> Once this feature is added, I would expect Katello to be able to store the
> PK (UUID) as a reference to each resource in Pulp. Katello needs to store
> Repository's UUID and version number as references for each repository
> version.
>
> When an URI for a particular resource is needed to pass it in as a
> reference to a method like sync or publish, a GET needs to be performed
> using the resource's PK. For repository versions the repository's PK and
> version number need to be used.
>
>
> [0] https://pulp.plan.io/issues/3633
>
> 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/94269fe3/attachment.htm>