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

Wed Oct 25 17:00:48 UTC 2017

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

I think this would be good to write up into Redmine and share a link to it.

On Wed, Oct 25, 2017 at 9:15 AM, Jeff Ortel <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>> 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
> >     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>
> >
> >
> >
> >
> > --
> >
> > Michael Hrivnak
> >
> > Principal Software Engineer, RHCE
> >
> > Red Hat
> >
>
>
> _______________________________________________
> 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/20171025/895cdc90/attachment.htm>