Project

Profile

Help

Task #110

Updated by mhrivnak over 5 years ago

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:
# Can the repo_content_unit collection be converted to mongoengine before the unit model?
# Can we support an environment where not all units are converted at once?
# Should we create a "file" unit as a test case in the platform (with importer & distributor) that can be used to prove things out?
# How do we support the /types/ api endpoints with a mixture of non-unit & unit models?
# Can we load the models via entrypoints and deprecate the types.json?
# How does Nodes interact with the mongoengine unit models?
# How do we deal with unit types that have no data on the filesystem?
# How do we deal with unit types that have a single file on the filesystem?
# 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.
# How do we deal with unit types where multiple units share a single piece of content on the filesystem (ostree)?

Deliverables:
* a diagram of unit data modeling

Back