<div dir="ltr"><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></div></div></div></blockquote><div><br></div><div>Perhaps we should dig into the modeling options more. To me, it is clear that the simpler model, which has been considered and discussed in the past, is not viable because of the incredibly high number of relationships it would produce. The model I proposed is slightly more complex, but still easily understood and reasoned about. It's been vetted many times by the team both as a group and as individuals, so I don't think there's any particular risk with it. The PoC even includes correctness tests of all the behaviors I could think of.</div><div><br></div><div>I appreciate all ideas and alternatives. We should compare and contrast all potential options. But I don't think this one suddenly needs to be a wrench in the gears.</div><div><br></div><div>Does anyone have a preference on how to move this discussion forward? New email thread? Live meeting?</div><div><br></div><div>I am admittedly coming at this with the bias of someone who has been thinking about and working on this problem for a long time. But that also gives me the confidence to know that we are very close to being able to move forward with implementation. I think we just need:</div><div><br></div><div>- Final agreement on the model. I think we're not far from this.</div><div>- Define basic use cases. Is there more to do here? I think this is well in-hand.</div><div>- Make REST API decisions. This is more a matter of deciding on certain general approaches we will take with specific REST API challenges, such as how to make an endpoint that acts on multiple resources. There's not much specific to repo versions. It just happens to be the first such example we're discussing as a wide group.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><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></div></div></div></blockquote><div><br></div><div>The main reason I think this is important for 3.0 is that if it doesn't land there, it may not be viable until 4.0.</div><div><br></div><div>And I really don't think this has to impact our timeline. It may actually be more work for 3.0 to have a REST API that's compatible with a data model we don't have in-place, using predictions of what it's likely to be, rather than just using the real models, serializers and views up-front. You all know how committed I am to deferring anything we can to 3.1+. But I see this one as very important to getting Pulp 3's foundation right.</div><div><br></div><div>I do see this behavior as a huge advantage for Pulp and critical to the kinds of workflows we need to advocate and facilitate. If there's one critique we hear over and over, it's that promotions and small changes should be crazy fast. This is the path to making that a reality.</div></div><div><br></div>-- <br><div class="m_-6602520251234583039gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">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!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div></div>