The pulp_deb team had a brain storming session this morning on how to improve Package upload workflows in the plugin.
One of the main things we struggled with, is the can of worms of edge cases and counterintuitive behaviour when some repository has both synchronized and uploaded content in it. E.g.: What happens with the uploaded content when a new sync uses mirrored policy? (The uploaded content is chucked out of the new repo version.) How can optmized sync mode deal with these situations?
In APT world these edge cases are especially abundant, because of how metadata structures packages into “Release-Component-Architecture” groupings. E.g.: Should uploaded content go into the ReleaseComponent’s created via the sync or some kind of special “upload” component or similar? What if a upstream repository already has this component (think Pulp to Pulp syncs)?
One obvious conclusion is that as a matter of best practice, it is almost always best to use separate Pulp repos for synchronizing and uploading. We are now considering whether to take it further:
Proposal: Should we make it impossible to mix uploaded and synced content within a single repository?
The idea would be to have two types of repository in the plugin, one for upload and one for syncs so users simply can no longer mix these use cases.
Since this might be pretty restrictive for some expert users who know exactly what they are doing, we want to get as much input as pssible before we embark down that route.
Questions we are seeking input on:
- As a pulp_deb user, can you think of any critical use cases that are incompatible with this approach?
- As a pulpcore developer, how hard would it be to create multiple repo types in a plugin, some with sync API endpoint, others without?
- As a pulp_rpm developer, how problematic is a mix of mix uploaded and synced content in a single pulp_rpm repo?