<div dir="ltr"><div><div><div>What about a use case like this: "As a user, I want a repo to auto-update two base paths to maintain an old base_path for backwards compatibility during a base_path restructuring transition."<br><br></div>While ^ is not an MVP use case (I would argue), if we go forward with the feature to auto-update exactly 1 Distribution as part of the MVP, we cannot modify it later to handle N Distributions later due to semver. If we can't modify it later to be more general, then we can never fulfill a use case like ^ with this same feature. So I'm +0 an MVP that can auto-update N Distributions after publish but -1 on having the MVP perform exactly 1 Distribution update for the semver concerns above ^.<br><br></div>What do others think about ^?<br><br></div>-Brian<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 10:53 AM, 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"><span class=""><br>
<br>
On 10/25/2017 12:00 PM, Brian Bouterse wrote:<br>
> I'm +1 to this plan. There are several distinct points of value and I agree w/ all of them. I'm -0 to adding<br>
> the Publisher.distribution_id field for auto publishing as an MVP feature. It's an important feature, but also<br>
</span> ^^ did you mean auto distribution?<br>
<span class="">> if we had feedback from users later maybe we would position it differently. Maybe it should be a list of<br>
> distributions 0,1,* instead of 0,1 perhaps? Semantic versioning would constrain our ability to change this<br>
> after the 3.0 GA so we want to make sure what we do is right. This sounds right, but I'm not a user so I'm not<br>
> totally sure.<br>
</span>The known use case for auto distribution comes from pulp2. That is "As a user, I want my publication<br>
automatically available through one distribution." This is how pulp2 works today. There may be a use case<br>
for new publications to be automatically available through multiple distribution but I can't think of how that<br>
would be useful. Anyone else? And, no user has yet asked for it. Anyone asking for it?<br>
<span class=""><br>
><br>
> I think this would be good to write up into Redmine and share a link to it.<br>
<br>
</span><a href="https://pulp.plan.io/issues/3102" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/<wbr>3102</a><br>
<div><div class="h5"><br>
><br>
> On Wed, Oct 25, 2017 at 9:15 AM, Jeff Ortel <<a href="mailto:jortel@redhat.com">jortel@redhat.com</a> <mailto:<a href="mailto:jortel@redhat.com">jortel@redhat.com</a>>> wrote:<br>
><br>
><br>
><br>
> On 10/24/2017 09:29 PM, Michael Hrivnak wrote:<br>
> > There is a lot to like about this.<br>
> ><br>
> > Since the publisher is the one that would do the auto-updating of a distribution, it makes sense for it to own<br>
> > a reference to the distribution it should be updating.<br>
> ><br>
> > One question: how might this impact authorization? I know that's not in the MVP, but we'll need to tackle it<br>
> > eventually. It's convenient to say a specific user can do anything within the scope of a repo's path. This may<br>
> > not be worth worrying too much about, but it is something to factor in.<br>
> ><br>
> > Beyond what you identified, the first thing I thought of is that it solves a hotfix use case for which we've<br>
> > never offered a good solution. It goes like this:<br>
> ><br>
> > - user has a repo that changes over time<br>
> > - user makes a recent content set available to testing infrastructure, and eventually promotes that to<br>
> > production infrastructure. (in pulp 2 this was a copy between repos, and in pulp 3 of course it is multiple<br>
> > distributions aiming at different publications)<br>
> > - user has a testing cycle of days, weeks or perhaps months (common in certain industries) before a content<br>
> > set gets promoted<br>
> > - one day, the next heartbleed happens. User wants to forget all about the content set being tested and needs<br>
> > to just deploy the heartbleed fix on top of the content set currently in production.<br>
><br>
> Exactly. I was imagining the hotfix, Y stream, Z stream repositories/publications promoted through the same<br>
> set of distributions.<br>
><br>
><br>
> ><br>
> > So how does the user bypass the normal flow and hotfix the production content set? If Distribution was a<br>
> > top-level resource, it becomes simple. The user would create a new repo that is a clone of the content set<br>
> > currently in production, then add just the heartbleed fix. They could update their testing distribution to<br>
> > serve that publication for a brief period if they want, and then update the production distribution to serve<br>
> > it. After the dust settles, they can go back to the normal repository and its flow of changing content sets.<br>
> ><br>
> > What other factors can you folks think of?<br>
> ><br>
> ><br>
> > On Tue, Oct 24, 2017 at 4:24 PM, Jeff Ortel <<a href="mailto:jortel@redhat.com">jortel@redhat.com</a> <mailto:<a href="mailto:jortel@redhat.com">jortel@redhat.com</a>><br>
</div></div><div><div class="h5">> <mailto:<a href="mailto:jortel@redhat.com">jortel@redhat.com</a> <mailto:<a href="mailto:jortel@redhat.com">jortel@redhat.com</a>>>> wrote:<br>
> ><br>
> > During a discussion with Austin to resolve a problem implementing #3033, an interested question was<br>
> raised -<br>
> > "Why do Distributions needs to be owned by Publishers?" This question came up when considering a<br>
> solution to<br>
> > a DRF difficulty related to both Publications and Distributions being nested under publisher/ AND<br>
> related to<br>
> > each other. The idea being considered was to move Distributions to a top level resource. Here are the<br>
> > 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<br>
> intuitive to be<br>
> > a top level resource?<br>
> ><br>
> > Currently, the Distribution.publisher_id represents a parent-child relationship the mainly exists to<br>
> support<br>
> > automatic distribution. When the publisher creates a new publication, it is automatically<br>
> 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<br>
> 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<br>
> 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> <<a href="https://pulp.plan.io/issues/3033" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/<wbr>3033</a>><br>
> <<a href="https://pulp.plan.io/issues/3033" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/<wbr>3033</a> <<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>
</div></div>> > <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <mailto:<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a>> <mailto:<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<div class="HOEnZb"><div class="h5">> <mailto:<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> <<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>
> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a> <<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>
> ><br>
> ><br>
> ><br>
> > --<br>
> ><br>
> > Michael Hrivnak<br>
> ><br>
> > Principal Software Engineer, RHCE<br>
> ><br>
> > Red Hat<br>
> ><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Pulp-dev mailing list<br>
> <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <mailto:<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> <<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>
><br>
<br>
</div></div><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></div>