All the follow up work is now complete. The REST API returns relative paths
in the 'href' field. pulp_file, pulp_python, and pulp_ansible have been
updated with the required changes also.
On Fri, Aug 31, 2018 at 1:52 PM, Dennis Kliban wrote:
>
> On Fri, Aug 24, 2018 at 7:00 AM, David Davis
> wrote:
>
>> # Next Steps
>>
>> * enable the bindings by merging https://github.com/pulp/pulp/pull/3561
>> * Need to switch full hrefs currently returned for relative href's to be
>> returned. i.e. https://example.com/pulp/api/v3/repositories/file/1/ ->
>> /pulp/api/v3/repositories/file/1/
>> - Issue: https://pulp.plan.io/issues/3850
>>
>>
> The PR for enabling the bindings has been merged.
>
> I've also made a pulpcore PR[0] to address issue 3850.
>
> Next steps:
> - Update one functional test in pulp_file that expects a full URL.
> - Update the pulp_file docs to account for this change.
>
> [0] https://github.com/pulp/pulp/pull/3607
>
>
>> David
>>
>>
>> On Wed, Aug 8, 2018 at 12:22 PM David Davis
>> wrote:
>>
>>> Yea, the names here are in terms of the names we use today and are
>>> subject to the outcome of the field naming thread.
>>>
>>> David
>>>
>>>
>>> On Wed, Aug 8, 2018 at 12:17 PM Daniel Alley wrote:
>>>
As per the other discussion thread, I assume the names will actually
be _id, _type, _href?
Errata have both "id" and "type" fields, so if we're going to attempt
to keep the Pulp metadata field names out of the way of Content field
names, we need to do it for all of them.
On Wed, Aug 8, 2018 at 12:02 PM, David Davis
wrote:
> After recent meetings with stakeholders, we've arrived at a solution
> on how to handle ids and hrefs in the Pulp 3 API. The plan is to stop
> accepting hrefs for fields to instead rely solely on IDs. Hrefs will still
> be displayed in the API as a convenience to users but will not be accepted
> for fields in POST/PUT requests.
>
> In order to support polymorphic fields, we'll also be adding a 'type'
> field that will be returned for all objects that will contain the package
> name and resource name (e.g. pulp_file.FileContent). This will allow these
> objects to be posted to polymorphic fields like
> add_content_units/remove_content_units (see below).
>
> Lastly, we also propose un-nesting the repository versions endpont and
> making it a top-level resources. Filtering of repository versions
> associated with a specific repo will be handled by repo filters, e.g.
> /pulp/api/v3/repository_versions/?repository=3
>
>
> RETURNING DATA
>
> Return for all objects:
> - id
> - _href
> - type
>
> e.g. {'id': 4, 'type': 'pulp_file.FileContent', '_href': '
> http://localhost:8000/pulp/api/v3/content/file/files/4/'}
>
> This includes polymorphic fields (e.g. created_resource on TaskStatus)
>
>
> POSTING DATA
>
> Submitting data in general will use id only (no hrefs). For example:
>
> http http://localhost:8000/pulp/api/v3/remotes/file/3/sync
> repository=3
>
> Submitting polymorphic fields can be handled in the following way:
>
> add_content_units=[
> {'id': 4, 'type': 'pulp_file.FileContent', '_href': '
> http://localhost:8000/pulp/api/v3/content/file/files/4/'},
> {'id': 4, 'type': 'pulp_python.PythonContent', '_href': '
> http://localhost:8000/pulp/api/v3/content/python/p/4/'}
> ]
>
> Note: the only fields that are inspected are id and type. the rest are
> ignored. This simply allows users to pass back the data they receive from
> the content endpoint.
>
>
> We're holding off on proceeding until August 15th to allow time for
> comment. Please respond with any concerns or feedback before then.
>
>
> ___
> 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
