Project

Profile

Help

Story #3360

Updated by dkliban@redhat.com almost 7 years ago

***Motivation*** 

 As When a user I want single package needs to be able introduced to revert a the production environment, it's possible that the repository at repository version Y X that was used to repository version X from before. 

 As create the publication in production contains a user I want to treat completely different lifecycle environments as separate repositories. When set of content than the 'dev' latest repository is ready version Y (already in staging). Simply adding the new package to be promoted to the 'testing' repository, I want to create latest repository version will not produce a new repository version of 'testing' that is exactly suitable for production. Here are two possible ways to get a single package added to the same as a specific repository version of 'dev'.  

 Currently this can be achieved by: 

 production environment: 


 1. Determine which units need to be added to the latest repository version Y and which need to be removed to achieve the same content set as 'production' repository version X. 
 2. Create a new repository version Z by using information from step 1. 1 + new package. 
 3. Create a publication from the new repository version. 
 4. Update the production distribution to point to the new publication. 

 Step 1 Pros: repository version history is preserved in a single repository 
 Cons: requires the user to create some tooling for calculating figure out how to find delta between repository versions. When the diffs. The user then also has wants to make sure that nothing happens update Y to the Y+1, a delta needs to be calculated with respect to Z.  


 1. Create a 'hotfix' repository. 
 2. Create a 'hotfix' repository version Z from content in between when the diff was computed and when production repository version + hotfix package. 
 3. Create a publication from the new 'hotfix' repository version. 
 4. Update the production distribution to point to the new publication. 

 Pros: not difficult to execute 
 Cons: repository version history is created.  

 split between original repository and 'hotfix' repository. There is no way to tell that the hotfix repository is related to the original repository. 


 ***Solution*** 

 A user should be able to create a repository version by specifying an href for another repository a base version. This would remove the responsibility of finding deltas between repository versions from the user. 

 The /api/v3/repositories/<id>/versions/ API should accept a 'mirror_repository_version'. 'base_version_href'. When specified, the new repository version is created to be exactly like the repository base version specified. This parameter can not be used in combination with plus any 'add_content_units' and minus any 'remove_content_units'.

Back