Pulp

This ticket is a draft for the moment, so we can take time and have discussion and think through what the best design is for the Unit class with mongoengine. Let's keep this notice at the top and [Draft] in the subject until we have the details worked out.

Objectives:

• Ensure that every Unit has user_metadata.

Questions:

1. Can the repo_content_unit collection be converted to mongoengine before the unit model?
2. Can we support an environment where not all units are converted at once?
3. How do we support the /types/ api endpoints with a mixture of non-unit & unit models?
4. Can we load the models via entrypoints and deprecate the types.json?
5. How does Nodes interact with the mongoengine unit models?
6. Can we have base model classes that are used by the plugin?
7. How do we deal with migrations to the unit models as we standardize?
8. How do we deal with unit types that have no data on the filesystem?
9. How do we deal with unit types that have a single file on the filesystem?
10. How do we deal with unit types that have multiple files on the filesystem? For units with multiple files, what if they have very large numbers of files (for example, some yum repos nest entire additional repositories using the treeinfo file.
11. How do we deal with unit types where multiple units share a single piece of content on the filesystem (ostree)?
12. Can the unit model emulate the transfer unit such that we can replace the transfer units with the mongoengine model?

Deliverables:

• a diagram of unit data modeling
• a wiki describing the plan
• a deep dive on the plan for the team

Results:

Wiki & Diagram can be found at: https://fedorahosted.org/pulp/wiki/ConvertingUnitsToMongoengine