On 10/31/2017 03:07 PM, Brian Bouterse wrote: > 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."
Great use case, Brian. Yes. I agree this is compelling. I have updated the issue to reflect that the Distribution.publisher_id will remain to support the one-to-many relationship and indicate automatic distribution instead of ownership. [0] https://pulp.plan.io/issues/3102 > > 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 ^. > > What do others think about ^? > > -Brian > > > On Fri, Oct 27, 2017 at 10:53 AM, Jeff Ortel <[email protected] > <mailto:[email protected]>> wrote: > > > > On 10/25/2017 12:00 PM, Brian Bouterse wrote: > > 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 > > the Publisher.distribution_id field for auto publishing as an MVP > feature. It's an important feature, but also > ^^ did you mean auto > distribution? > > if we had feedback from users later maybe we would position it > differently. Maybe it should be a list of > > distributions 0,1,* instead of 0,1 perhaps? Semantic versioning would > constrain our ability to change this > > 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 > > totally sure. > The known use case for auto distribution comes from pulp2. That is "As a > user, I want my publication > automatically available through one distribution." This is how pulp2 > works today. There may be a use case > for new publications to be automatically available through multiple > distribution but I can't think of how that > would be useful. Anyone else? And, no user has yet asked for it. > Anyone asking for it? > > > > > I think this would be good to write up into Redmine and share a link to > it. > > https://pulp.plan.io/issues/3102 <https://pulp.plan.io/issues/3102> > > > > > On Wed, Oct 25, 2017 at 9:15 AM, Jeff Ortel <[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > > > 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 <[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>>> 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> > <https://pulp.plan.io/issues/3033 <https://pulp.plan.io/issues/3033>> > > <https://pulp.plan.io/issues/3033 <https://pulp.plan.io/issues/3033> > <https://pulp.plan.io/issues/3033 <https://pulp.plan.io/issues/3033>>> > > > > > > > > > _______________________________________________ > > > Pulp-dev mailing list > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > > https://www.redhat.com/mailman/listinfo/pulp-dev > <https://www.redhat.com/mailman/listinfo/pulp-dev> > <https://www.redhat.com/mailman/listinfo/pulp-dev > <https://www.redhat.com/mailman/listinfo/pulp-dev>> > > <https://www.redhat.com/mailman/listinfo/pulp-dev > <https://www.redhat.com/mailman/listinfo/pulp-dev> > <https://www.redhat.com/mailman/listinfo/pulp-dev > <https://www.redhat.com/mailman/listinfo/pulp-dev>>> > > > > > > > > > > > > > > > -- > > > > > > Michael Hrivnak > > > > > > Principal Software Engineer, RHCE > > > > > > Red Hat > > > > > > > > > _______________________________________________ > > Pulp-dev mailing list > > [email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > https://www.redhat.com/mailman/listinfo/pulp-dev > <https://www.redhat.com/mailman/listinfo/pulp-dev> > <https://www.redhat.com/mailman/listinfo/pulp-dev > <https://www.redhat.com/mailman/listinfo/pulp-dev>> > > > > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] <mailto:[email protected]> > https://www.redhat.com/mailman/listinfo/pulp-dev > <https://www.redhat.com/mailman/listinfo/pulp-dev> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
