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 <jsher...@redhat.com> wrote: > > > On 04/30/2018 10:05 AM, David Davis wrote: > > So what I’d probably propose is exposing the UUIDs in the response and > then extending HyperlinkedRelatedFields to accept UUID or href. Then > third parties like Katello could store and just use UUIDs (and not worry > about hrefs). > > Regarding hrefs though, hostname and port don’t matter. The app just looks > at the relative path. It looks like changing the deployment path causes > problems though. > > > It matters if you are a client and are fetching stored hrefs. > > Justin > > > > > David > > On Mon, Apr 30, 2018 at 9:58 AM, Justin Sherrill <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/msg00004.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 <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 <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/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