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

[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 

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

[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 
> 

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

[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
> 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-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 

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

[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
>> >> > 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 

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

[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
> >> > 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
> >>> > wrote:
> >>>
> >>> I can't remember why we 

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

[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
>> > 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
>>> > 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

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

[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
>>> 

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

[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

[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

[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

[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

[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

[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
> 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-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

[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

[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
> 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] Port Pulp3 to use RQ

[Brian Bouterse]

Through several rebases, now all PRs are showing the RQ PRs on Travis as
passing with pulp-smash. Several points of feedback have been addressed.

If you're interested in commenting on these PRs or trying them out, please
do. I hope to merge after the other taking system maintainers @dalley and
@daviddavis have finished their testing/review and barring any other calls
for delay or blocking concerns.

If there are any questions, issues, or concerns, please reach out, and we
can talk through them.



On Fri, Apr 20, 2018 at 4:18 PM, Brian Bouterse  wrote:

> I put together a prototype and posted the PRs. I'm still working to get
> Travis happy, but locally 100% of smash tests using these branches. It's
> worked very reliably for me so far. There are no gaps in the pulp feature
> set on top of RQ.
>
> I hope people test it out and give some feedback. See the commit messages
> for details on what was done. Here are the PRs:
>
> https://github.com/pulp/pulp/pull/3454
> https://github.com/pulp/pulp_file/pull/72
> https://github.com/pulp/devel/pull/146
> https://github.com/PulpQE/pulp-smash/pull/960
>
> Feel free to send questions here or to the PR. Any feedback is welcome.
>
> -Brian
>
>
>
>
> On Thu, Mar 22, 2018 at 5:28 PM, Milan Kovacik 
> wrote:
>
>> +1 I like RQ and I like http://python-rq.org/docs/testing/ esp.
>> there's Fakeredis ;)
>>
>>
>> --
>> milan
>>
>>
>> On Thu, Mar 22, 2018 at 6:58 PM, Brian Bouterse 
>> wrote:
>> > Thanks for all the discussion both on list and on irc. After more
>> > investigation, it sounds like there are no feature gaps, but we will
>> need to
>> > incorporate this workaround to cancel a task that is already running.
>> >
>> > The feedback I've heard on the idea is that it's valuable and looks
>> > feasible, but we won't really know until we prototype it a bit. Based
>> on the
>> > technical outline in the previous email, I believe it can be prototyped
>> in a
>> > day or two. I plan to do this soon, once I contribute to a few other
>> > required-for-beta planning items first. I'll post my PR to see what
>> other
>> > think of the change, probably next week.
>> >
>> >
>> >
>> > On Wed, Mar 21, 2018 at 6:41 PM, Daniel Alley 
>> wrote:
>> >>
>> >> I meant in the sense that, what is the aftermath when it comes back
>> >> online, and is it screwed up in ways that cause side effects.
>> >>
>> >> On Wed, Mar 21, 2018 at 5:02 PM, Jeremy Audet 
>> wrote:
>> >>>
>> >>> > RQ does not support revoking tasks.  If you send the worker a
>> SIGINT,
>> >>> > it will finish the task and then stop processing new ones.  If you
>> send the
>> >>> > worker SIGKILL, it will stop immediately, but I don't think it
>> gracefully
>> >>> > handles this circumstance.
>> >>>
>> >>> Nothing handles SIGKILL gracefully. Processes can't catch that signal.
>> >>> `kill -9 $pid` sends SIGKILL.
>> >>>
>> >>> If one is looking for a way to gracefully, immediately kill an RQ
>> >>> worker, then SIGTERM may do the trick. Anecdotally, many processes
>> >>> handle this signal in a hurried fashion. Semantically, this is
>> >>> appropriate: SIGINT is the "terminal interrupt" signal (Ctrl+c sends
>> >>> SIGINT), whereas SIGTERM is the "termination signal."
>> >>
>> >>
>> >
>> >
>> > ___
>> > 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