Project

Profile

Help

Task #5201

closed

Story #5110: [Epic] As a user, I can manage Kickstart repositories

Create the model(s) for distribution trees as Content models

Added by daviddavis over 4 years ago. Updated about 4 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
Groomed:
Yes
Sprint Candidate:
No
Tags:
Sprint:
Sprint 58
Quarter:

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

Actions #2

Updated by daviddavis over 4 years ago

  • Description updated (diff)
Actions #3

Updated by bmbouter over 4 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.

Actions #4

Updated by bmbouter over 4 years ago

  • Groomed changed from No to Yes
  • Sprint set to Sprint 57
Actions #5

Updated by fao89 over 4 years ago

  • Assignee set to fao89
Actions #6

Updated by bmbouter over 4 years ago

  • Description updated (diff)
  • Status changed from NEW to ASSIGNED
Actions #7

Updated by bmbouter over 4 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?

Actions #8

Updated by ttereshc over 4 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.

Actions #9

Updated by bmbouter over 4 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.

Actions #10

Updated by ttereshc over 4 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.

Actions #11

Updated by fao89 over 4 years ago

  • Status changed from ASSIGNED to POST
Actions #12

Updated by rchan over 4 years ago

  • Sprint changed from Sprint 57 to Sprint 58

Added by Fabricio Aguiar over 4 years ago

Revision d9591bd0 | View on GitHub

Kickstart models

closes #5201 https://pulp.plan.io/issues/5201

Actions #13

Updated by Anonymous over 4 years ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100
Actions #14

Updated by ttereshc over 4 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE
Actions #15

Updated by ttereshc about 4 years ago

  • Sprint/Milestone set to Pulp 3.x RPM (Katello 3.16)

Also available in: Atom PDF