<div dir="ltr">Reply-all fail; Forward my accidental direct reply.<br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Kodiak Firesmith</b> <span dir="ltr"><<a href="mailto:kfiresmith@gmail.com">kfiresmith@gmail.com</a>></span><br>Date: Fri, May 26, 2017 at 10:38 AM<br>Subject: Re: [Pulp-dev] versioned repositories<br>To: Brian Bouterse <<a href="mailto:bbouters@redhat.com">bbouters@redhat.com</a>><br><br><br><div dir="ltr"><div>Piling on to Bouter's comments, here,</div><div><br></div>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. <div><br></div><div>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. </div><div><br></div><div>Just my $0.02</div><span class="HOEnZb"><font color="#888888"><div><br></div><div> - Kodiak</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 10:31 AM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>+1 to determining the REST API because we have to get that right due to semver.<br></div><div><br></div><div>@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).<br></div><div><br></div><div>@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.<br><br>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.<br><br></div><div>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.<br></div><br></div>-Brian<br><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 9:30 AM, Ina Panova <span dir="ltr"><<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I am leaning towards what Mike expresses - make the decisions now w/r to data model and REST API.<br><br>With regards to: "Implementing a
feature internally in an MVP and not fully exposing it to the user does not make
sense." <br></div>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.<br></div>But people usually expect more or less this ^ when it comes to a completely new and drastically big change.<br></div><div class="gmail_extra"><br clear="all"><div><div class="m_5622950230972110130m_-2557322783226048553m_-3300122703747686922m_-2290365398876527406m_3735654232251130645gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div>
<br><div class="gmail_quote"><div><div class="m_5622950230972110130m_-2557322783226048553m_-3300122703747686922m_-2290365398876527406h5">On Wed, May 24, 2017 at 11:05 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_5622950230972110130m_-2557322783226048553m_-3300122703747686922m_-2290365398876527406h5"><div dir="ltr"><div class="gmail_extra"><span><br><div class="gmail_quote">On Wed, May 24, 2017 at 3:38 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Internals we can change/rework all day, but the thing we need to
get right is the API because of semver.</blockquote></div><br></span>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'd much rather make the decisions now and go out the door with the data model and associated REST API we want.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'll also emphasize that "<span style="font-size:12.8px">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).</span></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<span><br clear="all"><div><br></div>-- <br><div class="m_5622950230972110130m_-2557322783226048553m_-3300122703747686922m_-2290365398876527406m_3735654232251130645m_1072761366899690565gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Michael</span> <span style="margin:0px;padding:0px">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Principal Software Engineer</span><span style="margin:0px;padding:0px">, <span style="margin:0px;padding:0px">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px">Red Hat</p></div></div>
</span></div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div></div><br></div>