[Pulp-dev] Consider moving distribution to top level resource.

Brian Bouterse bbouters at redhat.com
Tue Oct 31 20:07:35 UTC 2017


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."

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> 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
>
> >
> > On Wed, Oct 25, 2017 at 9:15 AM, Jeff Ortel <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>>> 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
> >>
> >     >
> >     >
> >     >     _______________________________________________
> >     >     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>>
> >     >
> >     >
> >     >
> >     >
> >     > --
> >     >
> >     > Michael Hrivnak
> >     >
> >     > Principal Software Engineer, RHCE
> >     >
> >     > Red Hat
> >     >
> >
> >
> >     _______________________________________________
> >     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>
> >
> >
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171031/2d75e778/attachment.htm>


More information about the Pulp-dev mailing list