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 <bbout...@redhat.com
<mailto:bbout...@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
<mhriv...@redhat.com <mailto:mhriv...@redhat.com>> wrote:
On Fri, May 26, 2017 at 10:31 AM, Brian Bouterse
<bbout...@redhat.com <mailto:bbout...@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@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
