Project

Profile

Help

Story #5202

Updated by bmbouter over 4 years ago

For now, mirror all images and a main yum repo from a kickstart repo. 

 h3. Design 

 Have the FirstStage of pulp_rpm try to download and parse the tree info file. From this file create the declarative content unit of the DistributionTree model (the actual content unit). Have the Stages API process this unit like any other. 

 When actually saving the DistributionTree content unit in the ContentUnitSaver stage, have any additional model creation happen then. 


 h3. Syncing Sub Repos 

 Some entries in the kickstart tree identify a "sub repo". that's not an official term, but it's intended to mean another valid repodata folder that identifies another set of RPMs that is outside of the main /repodata/ folder. One main challenge is efficiently syncing these "sub repos". 

 One easy solution we came up with is To recap the sub-repo modeling a XXXXX model has a ForiegnKey to instantiate multiple RPMDeclarativeVersion instances, one for each sub-repo Repository and one is a OneForOne field ForeignKey. When syncing, the goal is that the same repodata parsing code in FirstStage is reused in parsing these repodata files for sub-repos. The difference is that the main repo. This allows each one repo Stages API is inspecting repo A for units already existing, while subrepo 1 needs to work out of a different repository. inspect Repo B, and subrepo 2 inspects Repo C, etc. 

 The trick challenge is to not instantiate more than 1 at once that way rate limiting, etc won't be an issue. 


 h2. What about remotes for sub Repos? 

 We should create an in-memory Remote for currently the sub-repos. It shouldn't modify the real Remote because we don't want Stages API only are able to do that. Also it needs all the settings from the original remote, e.g. proxy settings, ssl, etc handle "one repo" so all those should    be copied. The one difference needs to be the url, it needs achieve ^ design we would need to be appended with extend the sub-path url of Stages API itself. I believe this is do-able and reasonable, but it's a required change. It's effectively making the sub-repo from the treeinfo file. Stages API "multi-sync" capable. 

Back