Project

Profile

Help

Task #3102

Updated by amacdona@redhat.com over 6 years ago

This task is to: 
 # Move distributions to the top level resource (no longer owned by a publisher). 
 # update the uniqueness constrains for distribution name (no longer unique together with publisher name) 
 # remove auto_updated field 
 # rename publisher_id to publisher, this field should be optional. (If this is set, it implies that the distribution will be automatically updated by that publisher.) 
 # Update the publish task to make sure publishers can update related distributions a distribution when a new publication is created. 


 h1. Background 

 During a discussion with Austin to resolve a problem implementing #3033, an interested question was raised - 
 "Why do Distributions needs to be owned by Publishers?"    This question came up when considering a solution to 
 a DRF difficulty related to both Publications and Distributions being nested under publisher/ AND related to 
 each other.    The idea being considered was to move Distributions to a top level resource.    Here are the benefits: 

 1. Resolves current DRF nesting issue w/ #3033.    (This is minor). 
 2. A distribution could be updated to reference any publication.    This is more flexible. 
 3. Since Distribution.base_path is unique across all repositories/publishers, it might be more intuitive to be 
 a top level resource? 

 Currently, the Distribution.publisher represents a parent-child relationship the mainly exists to support 
 automatic distribution.    When the publisher creates a new publication, it is automatically associated to any 
 of the publisher's distributions marked as auto_updated=True. 

 There are two challenges to moving the Distribution to a top-level resources. 

 1. The distribution name is currently unique by (publisher, name). 
 2. This would break automatic distribution as currently implemented. 

 Here are a few options to resolving these challenges: 

 1. The name could be unique across all distributions.    This seems reasonable. 
 2. Redesign automatic distribution.    (see proposal below). 
 3. Reconsider automatic distribution. 

 h1. Proposal: 

 The use case for automatic distribution is similar to automatic publishing.    The user has updated a 
 repository; has published it; and now wants to consume content.    This could be done by making 3 API calls: 1 
 sync; 2 publish; 3 update-a-distribution.    But, based on pulp2, users want to do this with 1 API call. 


 New ER diagram: 

 <pre> 

 Publisher <---* Publication 
    |                  ^ (0,1) 
    |                  | 
    |                  | 
    v*                 | 
 Distribution -------- 
 </pre> 

 ---

Back