subject:"\[Pulp\-dev\] Pulp api seemingly incompatible with generated bindings"

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

2018-04-27 Thread Justin Sherrill


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/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/";,

    "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@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-27 Thread Dennis Kliban

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 
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/api/v3/repositories/bfc61565-89b
> 1-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@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-27 Thread David Davis

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?

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/msg4.html
[1] https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb247aba8bf5b4563
3eba414b79/pulp_file/app/viewsets.py#L54



David

On Fri, Apr 27, 2018 at 4:29 PM, Dennis Kliban  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 
> 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/api/v3/repositories/bfc61565-89b
>> 1-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@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread Justin Sherrill




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/msg4.html 

[1] 
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 > 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
mailto:jsher...@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/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/

",
    "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@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev




___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev





___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread David Davis

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.


David

On Mon, Apr 30, 2018 at 9:58 AM, Justin Sherrill 
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/msg4.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  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 
>> 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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread Justin Sherrill




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 > 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/msg4.html

[1]

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
mailto:dkli...@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
mailto:jsher...@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/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/

",
    "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@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev




___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev








_

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

2018-04-30 Thread David Davis

Sorry, I wasn’t clear. If you use them as parameters, the app doesn’t look
look at the hostname/port.

But yea, if the app uses them directly, then that’s a problem and it does
matter. So another reason to store/use UUIDs.


David

On Mon, Apr 30, 2018 at 10:24 AM, Justin Sherrill 
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 
> 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/msg4.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 
>> 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 
>>> 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@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev

>>>
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread Partha Aji

On Mon, Apr 30, 2018 at 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.
>
> +1. Exposing UUIDs is definitely preferable to using hrefs as ids.  "The
app just looks at the relative path"  -> what if pulp wants the flexibility
to change repositories end point (highly improbable but you never know).


> David
>
> On Mon, Apr 30, 2018 at 9:58 AM, Justin Sherrill 
> 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/msg4.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 
>> 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 
>>> 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@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev

>>>
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread Jeremy Audet

> +1. Exposing UUIDs is definitely preferable to using hrefs as ids.  "The
app just looks at the relative path"  -> what if pulp wants the flexibility
to change repositories end point (highly improbable but you never know).

Is it better, though? URIs were chosen specifically with immutability in
mind. "Cool URIs don't change." This is reflected in the application's
behaviour. If one changes an object's attributes (e.g. UUID), its href
doesn't change.

And in what case are hostname and port changing? If that's a common
deployment issue, I would contend that the deployment at hand is screwed up.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread Justin Sherrill




On 04/30/2018 10:46 AM, Jeremy Audet wrote:
> +1. Exposing UUIDs is definitely preferable to using hrefs as ids. 
 "The app just looks at the relative path"  -> what if pulp wants the 
flexibility to change repositories end point (highly improbable but 
you never know).


Is it better, though? URIs were chosen specifically with immutability 
in mind. "Cool URIs don't change." This is reflected in the 
application's behaviour. If one changes an object's attributes (e.g. 
UUID), its href doesn't change.


And in what case are hostname and port changing? If that's a common 
deployment issue, I would contend that the deployment at hand is 
screwed up.


I somewhat agree with you, however enough users have requested (or 
should i say demanded) this feature that katello now ships support for 
it natively.  Satellite does as well: 
https://access.redhat.com/solutions/1232133


I wish it were not a common issue, but it is, enough so that this is a 
requirement of any integration that katello does with pulp 3.


Justin




___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev


___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread David Davis

> If one changes an object's attributes (e.g. UUID), its href doesn't
change.

UUIDs don’t change. In fact, I think UUIDs are truly immutable compared to
hrefs which might change if hostname/port/scheme/deployment path/etc change.


David

On Mon, Apr 30, 2018 at 10:46 AM, Jeremy Audet  wrote:

> > +1. Exposing UUIDs is definitely preferable to using hrefs as ids.  "The
> app just looks at the relative path"  -> what if pulp wants the flexibility
> to change repositories end point (highly improbable but you never know).
>
> Is it better, though? URIs were chosen specifically with immutability in
> mind. "Cool URIs don't change." This is reflected in the application's
> behaviour. If one changes an object's attributes (e.g. UUID), its href
> doesn't change.
>
> And in what case are hostname and port changing? If that's a common
> deployment issue, I would contend that the deployment at hand is screwed up.
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread Tom McKay

If I'm deploying pulp in openshift, my "hostname" can vary greatly since
comms go through a router. Would you want to save
docker-registry.192.168.100.1.nip.io in the database?


apiVersion: v1
kind: Route
metadata:
  name: registry-access
spec:
  host: docker-registry.`minishift ip`.nip.io
  to:
kind: Service
name: docker-registry
weight: 100
  port:
targetPort: 5000-tcp
  tls:
termination: edge
insecureEdgeTerminationPolicy: Allow
status:


On Mon, Apr 30, 2018 at 10:53 AM, David Davis  wrote:

> > If one changes an object's attributes (e.g. UUID), its href doesn't
> change.
>
> UUIDs don’t change. In fact, I think UUIDs are truly immutable compared to
> hrefs which might change if hostname/port/scheme/deployment path/etc
> change.
>
>
> David
>
> On Mon, Apr 30, 2018 at 10:46 AM, Jeremy Audet  wrote:
>
>> > +1. Exposing UUIDs is definitely preferable to using hrefs as ids.
>>  "The app just looks at the relative path"  -> what if pulp wants the
>> flexibility to change repositories end point (highly improbable but you
>> never know).
>>
>> Is it better, though? URIs were chosen specifically with immutability in
>> mind. "Cool URIs don't change." This is reflected in the application's
>> behaviour. If one changes an object's attributes (e.g. UUID), its href
>> doesn't change.
>>
>> And in what case are hostname and port changing? If that's a common
>> deployment issue, I would contend that the deployment at hand is screwed up.
>>
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread Brian Bouterse

+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 
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 
> 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/msg4.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 
>> 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 
>>> 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@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev

>>>
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>
>
> ___
> Pulp-

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

2018-04-30 Thread Bryan Kearney

Is that true in practice? Most uses I see of APIs are around language
bindings where the url is not used as oftern.

-- 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  > 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
>> mailto:jsher...@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/msg4.html
>>> 
>>> 
>>> [1] 
>>> 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
>>> mailto:dkli...@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
>>> mailto:jsher...@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
>>>

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

2018-04-30 Thread Brian Bouterse

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  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  > > 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
> >> mailto:jsher...@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/msg4.html
> >>>  January/msg4.html>
> >>> [1] https://github.com/pulp/pulp_file/blob/
> 5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54
> >>>  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
> >>> mailto:dkli...@redhat.com>> wrote:
> >>>
> >>> I can't remember why we decided to remove UUID from the
> >>> responses. It sounds like we should add t

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

2018-04-30 Thread Dennis Kliban

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 
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 
> 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 > > > 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
>> >> mailto:jsher...@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 th

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

2018-04-30 Thread Jeff Ortel




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 > 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/msg4.html

[1]

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
mailto:dkli...@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
mailto:jsher...@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/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/

",
    "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@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev




___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread Austin Macdonald

I'm not sure how we should handle this, but I have a value question.

Our CLI and Bindings will be autogenerated, so they will always have the
full functionality of the REST API. Is there a reason our users would use
the REST API directly? If the REST API is only used through the
bindings/cli, what is the benefit of being HATEOAS compliant?


On Mon, Apr 30, 2018 at 3:21 PM, Jeff Ortel  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 
> 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/msg4.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 
>> 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 
>>> 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@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev

>>>
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>
>
> ___
> Pulp-dev mailing 
> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-04-30 Thread Brian Bouterse

@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.

To bring it back to Pulp, what we have in Pulp avoids complexity the same
way. The nice part is that we can generically process the input from the
client, i.e. a URL, into the model object. To start accepting IDs instead
of URLs then the server code now needs to know the classpath (hard coded)
for every argument received. This is the complexity we get to avoid via
URIs versus IDs.



On Mon, Apr 30, 2018 at 3:35 PM, Austin Macdonald  wrote:

> I'm not sure how we should handle this, but I have a value question.
>
> Our CLI and Bindings will be autogenerated, so they will always have the
> full functionality of the REST API. Is there a reason our users would use
> the REST API directly? If the REST API is only used through the
> bindings/cli, what is the benefit of being HATEOAS compliant?
>
>
> On Mon, Apr 30, 2018 at 3:21 PM, Jeff Ortel  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 
>> 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/msg4.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 
>>> 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 
 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 _hre

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

2018-04-30 Thread Dennis Kliban

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  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 
> 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/msg4.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 
>> 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 
>>> 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@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev

>>>
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>
>
> ___
> Pulp-dev mailing 
> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>
>
>
> ___
> Pulp-de

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

2018-04-30 Thread David Davis

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  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  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 
>> 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/msg4.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 
>>> 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 
 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 m

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

2018-05-01 Thread Bryan Kearney

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.

-- bk



signature.asc
Description: OpenPGP digital signature
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-05-01 Thread Brian Bouterse

On Tue, May 1, 2018 at 7:59 AM, Bryan Kearney  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@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-05-01 Thread David Davis

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  wrote:

>
> On Tue, May 1, 2018 at 7:59 AM, Bryan Kearney  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@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2018-05-17 Thread Dennis Kliban

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  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 
> wrote:
>
>>
>> On Tue, May 1, 2018 at 7:59 AM, Bryan Kearney 
>> 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@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25 matches

Site Navigation

Mail list logo

Footer information