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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> >> >> >> _______________________________________________ >> Pulp-dev mailing >> [email protected]https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
