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

David Davis daviddavis at redhat.com
Tue Jul 10 01:34:41 UTC 2018

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?

On Monday, July 9, 2018, Justin Sherrill <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
> 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.
> 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
> [1] 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>
> 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
>> David
>> On Tue, May 1, 2018 at 9:14 AM, Brian Bouterse <bbouters at redhat.com>
>> wrote:
>>> On Tue, May 1, 2018 at 7:59 AM, Bryan Kearney <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
>>> 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


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

More information about the Pulp-dev mailing list