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 <jsher...@redhat.com
<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/msg00004.html
<https://www.redhat.com/archives/pulp-dev/2018-January/msg00004.html>
[1]
https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54
<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
<dkli...@redhat.com <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
<jsher...@redhat.com <mailto:jsher...@redhat.com>> wrote:
Hi All!
I started playing around with pulp 3 and generated
bindings via https://pulp.plan.io/issues/3580
<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/
<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/
<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 <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<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
