[Pulp-dev] versioned repositories

[Michael Hrivnak]

On Fri, May 26, 2017 at 10:31 AM, Brian Bouterse <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170526/9218204e/attachment.htm>