# Distribution Tree issues ### Current state DB schema ![](https://i.imgur.com/YLGXvnT.png) ### Requirements - one distribution tree in a repo - there needs to be a main repo (distribution tree can be removed but the main repo should stay). - E.g. when there is no separate kickstart repo and all the content provided by one repo in the upstream. - http://mirror.centos.org/centos/7/os/x86_64/ - at least main repo is manageable (content can be added/removed, copied to/from) - one should be able to copy a distribution tree - one should be able to remove a distribution tree (without main repo) - one should be able to remove a repo containing a distribution tree ### Filed bugs - [Main issue which affects the rest] Copy https://pulp.plan.io/issues/7046 - Removal of a repo https://pulp.plan.io/issues/7096 - Orphan cleanup removes distribution tree content https://pulp.plan.io/issues/7130 - Migration from pulp2, when the same distribution tree is present in different repos https://pulp.plan.io/issues/6950 ### Solutions #### Current proposal for *Copy https://pulp.plan.io/issues/7046* - [dkliban] The copy (via modify API or recursive copy API) of a DistributionTree should create a new DistributionTree instance that references the new repository. This operation should also copy all the RPMs associated with the source repository. ### Questions (Future test cases) - [ttereshc] Why do Addon and Variant have foreign key to a Repository and not to an RpmRepository? - By the time kickstarts were implemented, we didn't have RpmRepository - [daviddavis] Can a user delete a repository that has a DistributionTree? I think this is a problem since the DistributionTree has a foreign key to the repo - if a repo is removed, a distribution tree should be removed as well - [daviddavis] What happens when a user removes a DistributionTree from a repo? - The distribution tree gets deleted from Pulp - [daviddavis] What happens when a user removes a DistributionTree from a repo and then adds it to another repo? - See previous answer - [daviddavis] What happens if I copy over a DistributionTree that already exists in the destination repo? I'm thinking this might happen in the promotion workflow. - copy in mirror mode? - Check with Katello around their use cases and expectations - [daviddavis] How does a user view the content in DistributionTree subrepos? - Don't worry about this for now ### Fixtures 1. Current fixtures has no RPM content https://fixtures.pulpproject.org/rpm-kickstart/ 2. Centos8 repo has a distribution tree with 2 variants but no addons. http://mirror.linux.duke.edu/pub/centos/8/BaseOS/x86_64/kickstart/ 3. RHEL7 7.1 repo has only 1 variant but it has 2 addons. http://cdn.stage.redhat.com/content/dist/rhel/server/7/7.1/x86_64/kickstart/ We need: - a repo1 which contains: - a distribution tree - a main repo with RPMs - 2 variants (one is a main repo, another is not, each needs to have RPMs in it) - 2 addons (each needs to have RPMs in it) - [stage2] needs to have a unique image for the sake of proper testing, known issues with parsing. - a repo2 wich contains a modified version of the repo1: - any content of the main repo changed - a repo3 wich contains a modified version of the repo1: - any content in one of the addons changed - a repo4 wich contains a modified version of the repo1: - any content in the variant which is NOT pointing to a main repo - productmd guy is lsedlar - if anything changes in .treeinfo when variant is updated (build timestamp, or any data in treeinfo file?) E.g. CentOS8 kickstart repo - [nice-to-have] a repo5 wich contains a modified version of the repo1: - an image is updated ### Test scenarios NOTE: Repos are from the seciton above - sync a repo1 (already have as a perf test) - sync repo1 and then sync repo 2 - changes in the main repo - sync repo1 and then repo 3 - changes in the addons - sync repo1 and then repo 4 - changes in a variant which is not a main repo - sync repo1, create a repo_copy and copy a distribution tree - sync repo1, create a repo_copy and copy a distribution tree, sync repo 2, and copy its distribution tree to the repo_copy - sync repo1, remove a distribution tree - the main repo should stay - <s>sync repo1, remove repo1 - removal of a repo should succeed and its distribution tree should be removed from pulp completely</s> - sync repo1 into my_repo, sync repo 2 into the my_repo, remove repo_version 1 - the my_repo has 2 repo versions, each repo version has its distribution tree. If repo version 1 is removed, its distribution tree has to be removed. - sync repo1 into my_repo, sync repo 2 into the my_repo, remove my_repo - the my_repo has 2 repo versions, each repo version has its distribution tree. All distribution trees have to be removed.