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

Justin Sherrill jsherril at redhat.com
Tue Jul 10 02:07:33 UTC 2018

On 07/09/2018 09:34 PM, David Davis wrote:
> The Pulp 3 CLI relies on the id field as it provides a an immutable 
> way for users to identify objects without using hrefs which wouldn’t 
> make sense in a CLI. So I think we’re keeping the id field.
> That said, I don’t see how it helps Katello unless Katello stores and 
> uses the id field to identify objects instead of hrefs?
Right, that's exactly what we would do.

> On Monday, July 9, 2018, Justin Sherrill <jsherril at redhat.com 
> <mailto:jsherril at redhat.com>> wrote:
>     Hi all,
>     I finally had some time to play with these and I do have some
>     concerns.  First i'd say that Dennis' work to get the swagger
>     generation working with href's seemed to work really well!  I did
>     find one small bug(1) that may be isolated to the ruby bindings,
>     but seems like a serialization issue potentially.
>     However I do have some concerns.  According to Dennis, upstream
>     swagger does not seem open to accepting this change that utilizes
>     href's in its api calls.  This leaves us all in a bit of a pickle as:
>     1) pulp seems to suggest to use hrefs (and may remove ids in the
>     future?)
>     2) swagger does not (and will never?) support referencing objects
>     by href's in the future
>     Thus for katello to use href's, we would need to use an altered
>     version of swagger that someone maintains.  While the patch is
>     small, I'm not sure either of our teams are super well positioned
>     to maintain something like this long term.
>     It might make sense for the pulp team to maintain this, as the
>     requirements are being suggested by the pulp team, however it
>     doesn't seem like ya'll will actually be using any generated
>     bindings which doesn't seem like a good dependency.
>     It might make sense for the Katello team but I would say we're
>     only using hrefs because they seem to be what was recommended.  In
>     both cases its a different technology (java) with a different
>     built system.  I could see 3 years from now some issue coming up
>     that requires us to update to a newer swagger version and untangle
>     this when no one that was involved in this decision was around.  I
>     don't really see either of our teams maintaining a fork of the
>     swagger code generation as a good long term solution.
>     May I suggest that we either:
>      a) Work harder to get the code change upstream
>     or if that does not seem to be going well
>      b) commit to continue responding with ids (in addition to hrefs)
>     in all object responses
>     (1) https://pulp.plan.io/issues/3843
>     <https://pulp.plan.io/issues/3843>
>     On 05/17/2018 06:26 PM, Dennis Kliban wrote:
>>     I have been able modify the default behavior of swagger-codegen
>>     to produce bindings that use relative URLs to identify resources.
>>     The required changes can be seen here[0]. The compiled jar is
>>     available for download here[1].
>>     The following command can be used to generate python bindings.
>>     Replace 'python' with 'ruby' and you'll get ruby bindings. The
>>     json file is the API schema returned by the Pulp server at
>>     http://localhost:8000/api/v3/docs/api.json
>>     <http://localhost:8000/api/v3/docs/api.json>.
>>     java -jar ./swagger-codegen-cli.jar generate -i
>>     ~/Downloads/pulp3-api.json -l python -o some_directory_name
>>     [0]
>>     https://github.com/dkliban/swagger-codegen/commit/e31e96769864b73b06bd99f5e20e4720562539b9
>>     <https://github.com/dkliban/swagger-codegen/commit/e31e96769864b73b06bd99f5e20e4720562539b9>
>>     [1]
>>     https://repos.fedorapeople.org/pulp/pulp/swagger/swagger-codegen-cli.jar
>>     <https://repos.fedorapeople.org/pulp/pulp/swagger/swagger-codegen-cli.jar>
>>     On Tue, May 1, 2018 at 11:18 AM, David Davis
>>     <daviddavis at redhat.com <mailto:daviddavis at redhat.com>> wrote:
>>         We’ve exposed IDs and I think the next goal will be to
>>         somehow let Katello use these IDs. I’ve opened a new story to
>>         solicit feedback on how this’ll work:
>>         https://pulp.plan.io/issues/3636
>>         <https://pulp.plan.io/issues/3636>
>>         David
>>         On Tue, May 1, 2018 at 9:14 AM, Brian Bouterse
>>         <bbouters at redhat.com <mailto:bbouters at redhat.com>> wrote:
>>             On Tue, May 1, 2018 at 7:59 AM, Bryan Kearney
>>             <bkearney at redhat.com <mailto:bkearney at redhat.com>> wrote:
>>                 On 04/30/2018 04:08 PM, Brian Bouterse wrote:
>>                 > @asmacdo, checking in on the why is great. I want
>>                 to try to articulate
>>                 > the benefits as I see them. Other perspectives and
>>                 discussion are welcome.
>>                 >
>>                 > The design of using URLs for referring things is a
>>                 design whose goal is
>>                 > to minimize complexity as the # of resources grows.
>>                 The Internet is a
>>                 > useful analogy here. When someone wants to tell me
>>                 how to find something
>>                 > on Instagram, if the article's name is
>>                 'cat_pic432642' and that's all I
>>                 > know, I'm going to have a hard time figuring out
>>                 the actual URL to ask
>>                 > Instagram's servers for, e.g.
>>                 /thepostsarehere/cat_pic432642. Even if I
>>                 > did know how Instram's url space was laid out, I
>>                 have to think about it
>>                 > different from all other web services I interact
>>                 with; now they're all
>>                 > different. This is the power of the URL itself. All
>>                 clients and all
>>                 > servers can use the uniform resource locator to
>>                 refer to things. I think
>>                 > this was the main contribution from Tim Berners-Lee
>>                 that allowed him to
>>                 > implement HTTP which has URIs at its heart.
>>                 But, to Austins Point, if folks are going to interact
>>                 with Pulp either
>>                 from the cli or from Go|rust|python libraries, they
>>                 will not see the
>>                 urls. In your analogy, you would most likely google
>>                 cat_pic432642  and
>>                 never know the url you are going to.
>>             I agree there will be much binding-based usage, and CLI
>>             usage, but there will always be users who will use httpie
>>             with some bash scripting calls instead. So from that
>>             perspective, the goals remain the same they have for
>>             years; we need to put forth the best, lowest-complexity
>>             REST API.
>>                 -- bk
>>             _______________________________________________
>>             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>
> -- 
> David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180709/98ffe9fd/attachment.htm>

More information about the Pulp-dev mailing list