[Pulp-dev] Consider moving distribution to top level resource.
Jeff Ortel
jortel at redhat.com
Wed Nov 1 14:27:26 UTC 2017
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 <jortel at redhat.com <mailto:jortel at redhat.com>> 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 <jortel at redhat.com <mailto:jortel at redhat.com>
> <mailto:jortel at redhat.com <mailto:jortel at redhat.com>>> 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 <jortel at redhat.com <mailto:jortel at redhat.com>
> <mailto:jortel at redhat.com <mailto:jortel at redhat.com>>
> > <mailto:jortel at redhat.com <mailto:jortel at redhat.com> <mailto: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>
> <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
> > > Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com> <mailto:Pulp-dev at redhat.com
> <mailto:Pulp-dev at redhat.com>> <mailto:Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
> > <mailto: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> <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
> > Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com> <mailto: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>
> <https://www.redhat.com/mailman/listinfo/pulp-dev <https://www.redhat.com/mailman/listinfo/pulp-dev>>
> >
> >
>
>
> _______________________________________________
> 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>
>
>
-------------- 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/20171101/41f4ce55/attachment.sig>
More information about the Pulp-dev
mailing list