[Pulp-dev] Pulp api seemingly incompatible with generated bindings
Justin Sherrill
jsherril at redhat.com
Mon Apr 30 13:58:02 UTC 2018
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/2c25abeb/attachment.htm>
More information about the Pulp-dev
mailing list