<div dir="ltr">There is a lot to like about this.<div><br></div><div>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.<br><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>- user has a repo that changes over time</div><div>- 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)</div><div>- user has a testing cycle of days, weeks or perhaps months (common in certain industries) before a content set gets promoted</div><div>- 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.</div><div><br></div><div>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.</div><div><br></div><div>What other factors can you folks think of?</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 24, 2017 at 4:24 PM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">During a discussion with Austin to resolve a problem implementing #3033, an interested question was raised -<br>
"Why do Distributions needs to be owned by Publishers?"  This question came up when considering a solution to<br>
a DRF difficulty related to both Publications and Distributions being nested under publisher/ AND related to<br>
each other.  The idea being considered was to move Distributions to a top level resource.  Here are the benefits:<br>
<br>
1. Resolves current DRF nesting issue w/ #3033.  (This is minor).<br>
2. A distribution could be updated to reference any publication.  This is more flexible.<br>
3. Since Distribution.base_path is unique across all repositories/publishers, it might be more intuitive to be<br>
a top level resource?<br>
<br>
Currently, the Distribution.publisher_id represents a parent-child relationship the mainly exists to support<br>
automatic distribution.  When the publisher creates a new publication, it is automatically associated to any<br>
of the publisher's distributions marked as auto_updated=True.<br>
<br>
There are two challenges to moving the Distribution to a top-level resources.<br>
<br>
1. The distribution name is currently unique by (publisher_id, name).<br>
2. This would break automatic distribution as currently implemented.<br>
<br>
Here are a few options to resolving these challenges:<br>
<br>
1. The name could be unique across all distributions.  This seems reasonable.<br>
2. Redesign automatic distribution.  (see proposal below).<br>
3. Reconsider automatic distribution.<br>
<br>
---<br>
<br>
Proposal to redesign automatic distribution.<br>
<br>
The use case for automatic distribution is similar to automatic publishing.  The user has updated a<br>
repository; has published it; and now wants to consume content.  This could be done by making 3 API calls: 1<br>
sync; 2 publish; 3 update-a-distribution.  But, based on pulp2, users want to do this with 1 API call.<br>
<br>
So, here is the proposal.<br>
<br>
1. Move distributions to the top level resource (no longer owned by a publisher).<br>
2. Remove Distribution.publisher_id and Distribution.auto_updated.<br>
3. Add (optional) Publisher.distribution_id.  When set, the referenced distribution will be updated with newly<br>
created publications.<br>
<br>
<br>
Publisher <---* Publication<br>
   |                ^ (0,1)<br>
   |                |<br>
   |                |<br>
   v (0,1)          |<br>
Distribution --------<br>
<br>
---<br>
<br>
I'm not convinced about all this but think we should consider.<br>
<br>
Thoughts?<br>
<br>
<br>
<a href="https://pulp.plan.io/issues/3033" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/<wbr>3033</a><br>
<br>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div>