[Pulp-dev] Single-Table Content API Changes, Performance Discussion

[Brian Bouterse]

I've done cprofile and code analysis and I don't think we can make the
single-content branches as fast as 'master' currently is. I posted the
reasoning for this analysis here [0]. Per the previous discussion, since
this performance improvement actually slows things down, we should just
close these branches. I believe we also want to adopt the API changes
@dalley posted [1][2] which need review and testing.

Any other ideas on how to make this work better are welcome. As it is now
I'll just say thanks to everyone who contributed to this effort, and a
special thank you to @dalley for doing so much coding and days worth of
effort on it.

[0]: https://pulp.plan.io/issues/3770#note-17
[1]: https://github.com/pulp/pulp/pull/3774
[2]: https://github.com/pulp/pulp_file/pull/133



On Tue, Nov 27, 2018 at 5:29 PM Dana Walker <dawalker at redhat.com> wrote:

> +1
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> <https://www.redhat.com>
> <https://red.ht/sig>
>
>
> On Mon, Nov 26, 2018 at 10:55 AM Jeff Ortel <jortel at redhat.com> wrote:
>
>>
>>
>> On 11/20/18 11:31 AM, Dennis Kliban wrote:
>>
>> On Mon, Nov 19, 2018 at 6:20 PM Daniel Alley <dalley at redhat.com> wrote:
>>
>>>
>>> Some of the API changes that are required by single-table-content would
>>> be beneficial even if we didn't go forwards with the modelling changes.
>>> For instance, currently we have single endpoints for each of
>>> repository_version/.../content/,  .../added_content/, and
>>> .../removed_content/ which mix content of all types together.  This makes
>>> it impossible for clients to expect the data returned to expect any
>>> particular schema.  What the single-table-content does is to provide
>>> separate query urls for each content type present in the repository
>>> version, which I believe is a usability win for us, and it's something we
>>> could implement without using any of the modelling changes.
>>>
>>>
>> The current behavior of the 'content' APIs is already causing a problem
>> for our OpenAPI 2.0 schema. OpenAPI 2.0 does not support polymorphic
>> responses. We are currently tracking problem with a bug[0]. The only way to
>> resolve this problem is to provide APIs that return heterogeneous types.
>>
>> [0] https://pulp.plan.io/issues/4052
>>
>>
>>> Besides being a general update, I'd like to start a discussion to
>>> understand:  is changing the Pulp 3 API so that it's organized around
>>> content type URLs OK with everyone? This resolves the usability issues of
>>> returning mixed types. Are there any downsides with this approach?
>>>
>>> To clarify what I mean on that last point -- by "content type URLs" I
>>> mean that where you currently get back the url "
>>> /pulp/api/v3/repository_version/.../content/" under the "_content"
>>> field on a repoversion, you would instead get back something like
>>>
>>> { "pulp_file.filecontent":
>>> "/pulp/api/v3/content/file/files/?repository_version=.. }
>>>
>>
>> I am +1 to making this change to our REST API.
>>
>>
>> +1
>>
>>
>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>
>> _______________________________________________
>> Pulp-dev mailing listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20181205/2157e1b8/attachment.htm>