[Pulp-dev] Pulp api seemingly incompatible with generated bindings
Dennis Kliban
dkliban at redhat.com
Mon Apr 30 18:44:00 UTC 2018
I looked into how the bindings are generated. The following is true for the
Python bindings. I am guessing that the same is probably true for the rest.
The bindings contain a configuration.py which let's the user set the
hostname, port, api prefix.
The bindings know the the format of each resource's URI. e.g. :
/remotes/file/{id}/. The user is expected to know the id of the Remote
resource when operating on this resource.
The methods for creating a resource all take a 'data' argument. The
bindings provide a python object for each resource. Instantiating one of
these objects produces the 'data' needed to pass into the
*_create(data=data) method.
The methods for 'sync' and 'publish' also accept a 'data' dictionary. The
bindings provide a RepositoryPublishURL and data =
swagger_client.RepositorySyncURL
objects. Instantiating either one produces a data dictionary needed to pass
into the corresponding method.
With all of this in mind, I think it makes sense to expose the UUID of each
resource. The clients would then need to store UUIDs for all the resources.
Repository Versions would be an exception. They would be identified using
the repository UUID and version number. Then we should change the REST API
to accept UUIDs of resources as references. The 'publish' endpoint would
need to accept a repository UUID and repository version number.
On Mon, Apr 30, 2018 at 12:53 PM, Brian Bouterse <bbouters at redhat.com>
wrote:
> Having full, relative urls returned would resolve the issues with the use
> case of changing the FQDN. I think it would also work with multi-host and
> container environments well. I agree w/ @thommckay's concerns about
> containers and full urls with FQDNs not working well.
>
> I'm not sure how using full, relative urls would or wouldn't resolve the
> bindings ID issue.
>
> I responded inline about IDs and hrefs too.
>
>
> On Mon, Apr 30, 2018 at 11:22 AM, Bryan Kearney <bkearney at redhat.com>
> wrote:
>
>> Is that true in practice? Most uses I see of APIs are around language
>> bindings where the url is not used as oftern.
>>
>
> In practice, using IDs instead of hrefs is common. I think REST motivates
> us towards the detail resource full, relative path being the universal
> descriptor of that resource. If we start referring to a detail resource by
> its ID only (not full relative path) then we tightly couple the client and
> server which gives back some of the benefits of REST.
>
>
>>
>> -- 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/5ffb33d8c70ffbb2
>> 47aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54
>> >>> <https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb
>> 247aba8bf5b45633eba414b79/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/a
>> pi/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/
>> >>> <http://localhost:8000/pulp/a
>> pi/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/>",
>> >>> "_latest_version_href": null,
>> >>> "_versions_href":
>> >>> "http://localhost:8000/pulp/a
>> pi/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/versions/
>> >>> <http://localhost:8000/pulp/a
>> pi/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
>> >
>>
>>
>>
>
> _______________________________________________
> 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/296c9d24/attachment.htm>
More information about the Pulp-dev
mailing list