[Pulp-dev] versioned repositories

Bryan Kearney bkearney at redhat.com
Wed Jun 21 20:56:58 UTC 2017

What was the outcome of this discussion?

-- bk

On 05/26/2017 04:48 PM, David Davis wrote:
> I agree on the ones that make the most sense to you as they seem to be 
> the most consistent. This to me seems inconsistent:
> .../foo/importers/<importer_natural_key>/sync
> .../foo/latest/publishers/<publisher_natural_key>/publish
> So +1 to the routes with explicit “/versions/” in the url.
> David
> On Fri, May 26, 2017 at 3:48 PM, Brian Bouterse <bbouters at redhat.com 
> <mailto:bbouters at redhat.com>> wrote:
>     After some in-person convo, @mhrivnak and I agree the most
>     productive next step is for us to look at the API planning. We will
>     continue with the regularly scheduled use calls starting on Tuesday
>     with the agenda 'status, alternate content sources, and revisiting
>     the JWT use cases based on discussion from [0].
>     We also need to understand what the API looks like with versioned
>     repos fully implemented. We also need to understand what an API
>     looks like that allows us to launch the MVP without versioned repos
>     and add them in later without creating a backwards compatibility
>     issue. This is also heavily related to the nested views of DRF and
>     the use of natural keys which are topics others are more familiar
>     with than I.
>     Here are some API options @mhrivnak and I talked about. Let .../foo/
>     be the API path to the repository named foo. I'm assuming nested URLs.
>     # Sync
>     The sync trigger never deals with versioned repos because it creates
>     versions and doesn't refer to them.
>     .../foo/importers/<importer_natural_key>/sync
>     # Publish options
>     .../foo/publishers/<publisher_natural_key>/publish        <---- no
>     version specifies assumes latest. When versioned repos we can add a
>     POST param version=xxxx to adding this during 3.1+
>     .../foo/latest/publishers/<publisher_natural_key>/publish      <----
>     launching without versioned repos would cause 'latest' to be the
>     only value that wouldn't 404. When version repos are added, latest
>     would be the natural key of the repo version (probably it's number).
>     .../foo/versions/latest/publishers/<publisher_natural_key>/publish    
>     <---- same as above only with the version repo being more of a
>     first-class resource.
>     # Listing Content options
>     .../foo/content/      <---- implicitly assumes the latest.
>     .../foo/versions/content/    <---- implicitly assumes the latest.
>     .../foo/versions/latest/content/   <---- explicitly latest.
>     Launching without versioned repos would cause 'latest' to be the
>     only value that wouldn't 404.
>     # Of all the ^, these make the most sense to me:
>     .../foo/importers/<importer_natural_key>/sync
>     .../foo/versions/<version_natural_key>/publishers/<publisher_natural_key>/publish      
>     <---- hard code <version_natural_key> to be 'latest' for MVP and
>     have no internal implementation of versioned repos
>     .../foo/versions/<version_natural_key>/content/      <---- hard code
>     <version_natural_key> to be 'latest' for MVP and have no internal
>     implementation of versioned repos
>     Please send thoughts and idea on the API.
>     [0]: https://pulp.plan.io/issues/2359 <https://pulp.plan.io/issues/2359>
>     -Brian
>     On Fri, May 26, 2017 at 11:58 AM, Michael Hrivnak
>     <mhrivnak at redhat.com <mailto:mhrivnak at redhat.com>> wrote:
>         On Fri, May 26, 2017 at 10:31 AM, Brian Bouterse
>         <bbouters at redhat.com <mailto:bbouters at redhat.com>> wrote:
>             +1 to determining the REST API because we have to get that
>             right due to semver.
>             @ipanova we want the same things, but I'm not sure how to
>             get there. You are considering including all versioned repo
>             functionality in the MVP. I like that idea lot better than
>             internally modelling it but not giving the users the
>             features. I really want versioned repos. In terms of how we
>             get there though, there are challenges in doing all of this
>             for the MVP (see below).
>             @all, If we want to make decisions now on the data model,
>             that is easier said than done. If I thought we could easily
>             agree on the data model, I would think that path is more
>             viable. There was a very long IRC conversation a few days
>             ago where an alternate data model was discussed and concerns
>             were raised with the prototype's data model in terms of
>             complexity. That led into a separate yet an equally long IRC
>             convo about the delete use cases of versioned repos. We can
>             work through those discussions, and in time we will, but it
>             will take time. We also need to involve the users, which
>             will take time too.
>         Perhaps we should dig into the modeling options more. To me, it
>         is clear that the simpler model, which has been considered and
>         discussed in the past, is not viable because of the incredibly
>         high number of relationships it would produce. The model I
>         proposed is slightly more complex, but still easily understood
>         and reasoned about. It's been vetted many times by the team both
>         as a group and as individuals, so I don't think there's any
>         particular risk with it. The PoC even includes correctness tests
>         of all the behaviors I could think of.
>         I appreciate all ideas and alternatives. We should compare and
>         contrast all potential options. But I don't think this one
>         suddenly needs to be a wrench in the gears.
>         Does anyone have a preference on how to move this discussion
>         forward? New email thread? Live meeting?
>         I am admittedly coming at this with the bias of someone who has
>         been thinking about and working on this problem for a long time.
>         But that also gives me the confidence to know that we are very
>         close to being able to move forward with implementation. I think
>         we just need:
>         - Final agreement on the model. I think we're not far from this.
>         - Define basic use cases. Is there more to do here? I think this
>         is well in-hand.
>         - Make REST API decisions. This is more a matter of deciding on
>         certain general approaches we will take with specific REST API
>         challenges, such as how to make an endpoint that acts on
>         multiple resources. There's not much specific to repo versions.
>         It just happens to be the first such example we're discussing as
>         a wide group.
>             Pulp2 never had these features that Pulp3 can launch without
>             them. I really want versioned repos, but not at the expense
>             of a longer Pulp3 release timeline. I can't stress enough
>             how getting Pulp3 out needs to be our focus and versioned
>             repos (aside from the API decisions) are unnecessarily
>             extending the release timeline. I think we need to turn our
>             focus to the plugin conversion work.
>         The main reason I think this is important for 3.0 is that if it
>         doesn't land there, it may not be viable until 4.0.
>         And I really don't think this has to impact our timeline. It may
>         actually be more work for 3.0 to have a REST API that's
>         compatible with a data model we don't have in-place, using
>         predictions of what it's likely to be, rather than just using
>         the real models, serializers and views up-front. You all know
>         how committed I am to deferring anything we can to 3.1+. But I
>         see this one as very important to getting Pulp 3's foundation right.
>         I do see this behavior as a huge advantage for Pulp and critical
>         to the kinds of workflows we need to advocate and facilitate. If
>         there's one critique we hear over and over, it's that promotions
>         and small changes should be crazy fast. This is the path to
>         making that a reality.
>         -- 
>         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

More information about the Pulp-dev mailing list