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]>> 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 > [email protected] <mailto:[email protected]> > https://www.redhat.com/mailman/listinfo/pulp-dev > <https://www.redhat.com/mailman/listinfo/pulp-dev> > > > > > -- > > Michael Hrivnak > > Principal Software Engineer, RHCE > > Red Hat >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
