[Pulp-dev] versioned repositories

[Ina Panova]

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/0bbe10df/attachment.htm>