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

Michael Hrivnak mhrivnak at redhat.com
Wed Oct 25 02:29:20 UTC 2017

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.

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> 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
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev


Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171024/a4f02f7e/attachment.htm>

More information about the Pulp-dev mailing list