[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