[Pulp-dev] versioned repositories

Michael Hrivnak mhrivnak at redhat.com
Wed May 24 21:05:33 UTC 2017


On Wed, May 24, 2017 at 3:38 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> Internals we can change/rework all day, but the thing we need to get right
> is the API because of semver.


I agree with this sentiment. But, I think it will be difficult to make the
API be compatible with a repo versioning world if the data model does not
match.

We could keep versioned repos out of the API and bolt something on later,
but I think we'd end up with an awkward solution, and it would be difficult
to guarantee that we'll be able to maintain compatibility without knowing
exactly what versioned repos will look like.

Or we could make a facade that looks partially like versioned repos but
doesn't actually implement it under the hood. But that would also be
awkward, more total work, and difficult to get 100% right without having
the model nailed down and agreed upon.

I'd much rather make the decisions now and go out the door with the data
model and associated REST API we want.

I'll also emphasize that "not fully exposing it to the user" is not
something I mean to be advocating for. I want to make repo versions a first
class concept in 3.0 and get people in that mindset. Like many things in
3.0, we can save time by not implementing every related feature and use
case. But just having the basics would already provide a lot of value. It
also helps us with other problems we're facing, such as race conditions
around orphans, and incomplete repo changes (for example if a sync task
fails hard in the middle).

I also want to point out that the REST API minutia we are discussing needs
to be thought through across our whole API. Removing repo versions from the
design would slightly reduce the total number of resources being RESTified,
but we'd be making most of the same decisions just on a different
collection.

The plugin work I think can proceed without this. Presumably the plugin API
will include a way to add and remove content, the implementation details of
which are not important to the plugin writer.

So I do share the same sentiment that I want to get 3.0 out ASAP and make
sure plugin work gets unblocked ASAP. But I think it is worth our time to
get the data model and associated REST API completed up-front, especially
when it comes to an important conceptual change such as this.

-- 

Michael Hrivnak

Principal Software Engineer, RHCE

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


More information about the Pulp-dev mailing list