[Pulp-dev] versioned repositories

[Brian Bouterse]

+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.

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.

I'm trying to talk us out of a really cool feature for the MVP. That's not
easy to do. Consider the costs and benefits of this activity. Maybe it's
worth it to others (not me). Please send more ideas and opinions so we make
the best choice together.

-Brian


On Fri, May 26, 2017 at 9:30 AM, Ina Panova <ipanova at redhat.com> wrote:

> I am leaning towards what Mike expresses - make the decisions now w/r to
> data model and REST API.
>
> With regards to: "Implementing a feature internally in an MVP and not
> fully exposing it to the user does not make sense."
> And what is the problem with fully exposing it? Yes it is new feature, yes
> it is unstable and most likely has issues and bugs.
> But people usually expect more or less this ^ when it comes to a
> completely new and drastically big change.
>
>
>
> --------
> Regards,
>
> Ina Panova
> Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
> On Wed, May 24, 2017 at 11:05 PM, Michael Hrivnak <mhrivnak at redhat.com>
> wrote:
>
>>
>> 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
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170526/179e6ed2/attachment.htm>