[Pulp-dev] Consider moving distribution to top level resource.

[Jeff Ortel]

On 10/24/2017 09:29 PM, Michael Hrivnak wrote:
> There is a lot to like about this.
> 
> Since the publisher is the one that would do the auto-updating of a distribution, it makes sense for it to own
> a reference to the distribution it should be updating.
> 
> One question: how might this impact authorization? I know that's not in the MVP, but we'll need to tackle it
> eventually. It's convenient to say a specific user can do anything within the scope of a repo's path. This may
> not be worth worrying too much about, but it is something to factor in.
> 
> Beyond what you identified, the first thing I thought of is that it solves a hotfix use case for which we've
> never offered a good solution. It goes like this:
> 
> - user has a repo that changes over time
> - user makes a recent content set available to testing infrastructure, and eventually promotes that to
> production infrastructure. (in pulp 2 this was a copy between repos, and in pulp 3 of course it is multiple
> distributions aiming at different publications)
> - user has a testing cycle of days, weeks or perhaps months (common in certain industries) before a content
> set gets promoted
> - one day, the next heartbleed happens. User wants to forget all about the content set being tested and needs
> to just deploy the heartbleed fix on top of the content set currently in production.

Exactly.  I was imagining the hotfix, Y stream, Z stream repositories/publications promoted through the same
set of distributions.


> 
> So how does the user bypass the normal flow and hotfix the production content set? If Distribution was a
> top-level resource, it becomes simple. The user would create a new repo that is a clone of the content set
> currently in production, then add just the heartbleed fix. They could update their testing distribution to
> serve that publication for a brief period if they want, and then update the production distribution to serve
> it. After the dust settles, they can go back to the normal repository and its flow of changing content sets.
> 
> What other factors can you folks think of?
> 
> 
> On Tue, Oct 24, 2017 at 4:24 PM, Jeff Ortel <jortel at redhat.com <mailto:jortel at redhat.com>> wrote:
> 
>     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_id 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_id, 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.
> 
>     ---
> 
>     Proposal to redesign automatic distribution.
> 
>     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.
> 
>     So, here is the proposal.
> 
>     1. Move distributions to the top level resource (no longer owned by a publisher).
>     2. Remove Distribution.publisher_id and Distribution.auto_updated.
>     3. Add (optional) Publisher.distribution_id.  When set, the referenced distribution will be updated with newly
>     created publications.
> 
> 
>     Publisher <---* Publication
>        |                ^ (0,1)
>        |                |
>        |                |
>        v (0,1)          |
>     Distribution --------
> 
>     ---
> 
>     I'm not convinced about all this but think we should consider.
> 
>     Thoughts?
> 
> 
>     https://pulp.plan.io/issues/3033 <https://pulp.plan.io/issues/3033>
> 
> 
>     _______________________________________________
>     Pulp-dev mailing list
>     Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>     https://www.redhat.com/mailman/listinfo/pulp-dev <https://www.redhat.com/mailman/listinfo/pulp-dev>
> 
> 
> 
> 
> -- 
> 
> Michael Hrivnak
> 
> Principal Software Engineer, RHCE 
> 
> Red Hat
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171025/0267ad17/attachment.sig>