Task #5201
closed
Story #5110: [Epic] As a user, I can manage Kickstart repositories
Create the model(s) for distribution trees as Content models
100%
Description
Content Model Design¶
The main model will be DistributionTree that inherits from pulp's Content object. Populate it with the field names from the productmd code [0]. Since some fields are unique only to their section, prefix them with the section name. For example, the name field in the release section will be release_name and base_product name will be base_product_name.
Add a new model DistributionTreeRepository that foreign key points at a distribution a DistributionTree content unit and a a Repository with RPMs. This table should store the variant info.
Lastly we need models for DistributionTree checksums, images, and addons.
[0] https://github.com/release-engineering/productmd/blob/master/productmd/treeinfo.py
Updated by daviddavis over 5 years ago
Updated by bmbouter over 5 years ago
- Subject changed from Create the model(s) for distribution trees to Create the model(s) for distribution trees as Content models
- Description updated (diff)
I'm grooming the story we the DistributionTree content object can be made. Also hopefully the checksums, images, and addons.
I don't understand the DistributionTreeRepository idea. Will we be associating DistributionTree w/ a repository like other Content? One nice thing if we can handle this like other content would is that it would allow the Stages API to not have to have custom stages.
Updated by bmbouter over 5 years ago
- Groomed changed from No to Yes
- Sprint set to Sprint 57
Updated by bmbouter over 5 years ago
- Description updated (diff)
- Status changed from NEW to ASSIGNED
Updated by bmbouter over 5 years ago
After reading this description and the productmd docs the DistributionTreeRepository makes more sense to me now. I think these statements are true:
A repository that has for example 3 distribution trees would have 3 DistributionTree units in it.
Each one of these units would be associated with another DistributionTreeRepository which is associated with a Repository that stores all the actual rpms.
Why not have the DistributionTree have the variant attributes on it and ForeignKey point to the Repository containing its content?
Updated by ttereshc over 5 years ago
I think one repository can have only one DistributionTree unit (aka one [.]treeinfo file).
As for the ForeignKey vs through model - a DistributionTree can reference any number of RPM repositories and it has attributes specific to each relation. I think through model is appropriate here.
Let me know if I misunderstood any of your comments, bmbouter.
Updated by bmbouter over 5 years ago
ttereshc wrote:
I think one repository can have only one DistributionTree unit (aka one [.]treeinfo file).
As for the ForeignKey vs through model - a DistributionTree can reference any number of RPM repositories and it has attributes specific to each relation. I think through model is appropriate here.
This clear is up for me thanks. I agree the through model is appropriate.
I guess my last question is, can a repository be referenced by multiple DistributionTree objects? Or at sync time is the Repository always dedicated to backing one DistributionTree?
Let me know if I misunderstood any of your comments, bmbouter.
Updated by ttereshc over 5 years ago
I guess my last question is, can a repository be referenced by multiple DistributionTree objects? Or at sync time is the Repository always dedicated to backing one DistributionTree?
I think that, in theory, a repository can be referenced by multiple DistributionTree objects.
In real life, it either never happens, or it happens very rarely. At least with the Centos/Fedora repos.
The only example which comes to mind is if there was some error in the treeinfo file, and it got updated/fixed in the remote kickstart repo. In this case, when we resync, we create a new DistributionTree unit and we could point to the existing RPM repos which hasn't changed.
If it's much simpler to have the limitation that the "Repository is always dedicated to backing one DistributionTree", I think it's ok, since it's a very rare case to have RPM repos reused.
Updated by fao89 over 5 years ago
- Status changed from ASSIGNED to POST
Added by Fabricio Aguiar over 5 years ago
Updated by Anonymous over 5 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset d9591bd03a17add0c2bd47b9f2e8c61d7c49874a.
Updated by ttereshc about 5 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
Updated by ttereshc almost 5 years ago
- Sprint/Milestone set to Pulp 3.x RPM (Katello 3.16)
.
Kickstart models
closes #5201 https://pulp.plan.io/issues/5201