[Pulp-dev] Fwd: versioned repositories

Fri May 26 14:39:19 UTC 2017

Reply-all fail; Forward my accidental direct reply.
---------- Forwarded message ----------
From: Kodiak Firesmith <kfiresmith at gmail.com>
Date: Fri, May 26, 2017 at 10:38 AM
Subject: Re: [Pulp-dev] versioned repositories
To: Brian Bouterse <bbouters at redhat.com>

Piling on to Bouter's comments, here,

Outsider's perspective:  As an end-user I'm holding off on a lot of
internal work and decision-making in our infra until Pulp 3 drops and I can
get a feel for interacting with it's base featureset and API.  So long as
the API doesn't change drastically at some future 3.x release I'd be much
more in favor of seeing a basic MVP release sooner rather than a fully
feature-complete MVP released later.

I have internal devs who are interested in creating plugins for things like
Node.JS NKM packages, but I've told them to hold off until P3 because big
changes are happening.

Just my $0.02

 - Kodiak

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.
>
> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/7ea73bc0/attachment.htm>