---
# System prepended metadata

title: Distribution Tree issues

---

# 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.