<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 24, 2013 at 11:53 PM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith@solidfire.com" target="_blank">john.griffith@solidfire.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">
All,</div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br>
</div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">I wanted to loop the larger community in on some discussions that have been taking place on #openstack-cinder.</div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">
<br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">During the Summit we talked about switching to Pecan for our API/Web framework. Since then we've registered a BP [1] and some pretty good progress has been made.</div>
<div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">Since starting this effort however we've been debating the best way to implement this change:</div>
<div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">1. Replace existing WSGI framework in the existing API versions</div>
<div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">In my opinion there's a bit of risk here with changing the entire framework tha the API is built on, and even though I'm confident this can be done I'm not sure of the return on the investment and really I don't see anything that compelling when you consider all of the changes in not only the API code but in the unit tests that would be affected.</div>
<div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">2. Bump to a new API version and isolate the changes to that new version</div>
<div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">This is my preference and IMO the right way to go, however there's no driving need for another API version bump in Cinder currently. I personally don't like the idea of bumping the API version for every release, even if we're keeping things stable and maintaining backward compatibility without issues. For me there isn't an overly compelling reason to justify this change for the H release.</div>
<div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">My plan is to go with option #2, and to push this change out until the I release. I'd like to know if anybody has strong feelings or justifications that we should consider on this before moving forward.</div>
<div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">Thanks,</div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">
John</div></blockquote></div><br><div class="gmail_extra">I've been involved with the discussions with John and was originally the person that proposed the pecan switch back at the Havana summit for Cinder in my session:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://etherpad.openstack.org/havana-cinder-api2-a-new-hope">https://etherpad.openstack.org/havana-cinder-api2-a-new-hope</a></div><div class="gmail_extra">
<br></div><div class="gmail_extra">I've been writing compatibility for both v1 and v2 in pecan/wsme and while I would absolutely love to see the wsgi implementation code go and xml serializing/deserializing code go, as John mentioned, I don't think it's worth it right now. It just took me writing around 5K lines of code to realize it.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Sort of reiterating John's points, there's a few reasons why I think we should wait for v3:</div><div class="gmail_extra"><br></div><div class="gmail_extra">
1) We'd likely drop v1 support in that release, so we don't have to worry about it anymore.</div><div class="gmail_extra"><br></div><div class="gmail_extra">2) Make reviewing a lot easier since it's not one big commit that changes all controllers and tests. Instead have v3 be introduced using pecan with a commit for each controller and tests. Eventually allow v3 to be served by cinder-api in the ending commit.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">3) v2 controller code and tests don't have to be updated to use pecan. v2 will continue to use paste and v3 will use pecan.</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">This is the same approach that Ceilometer has done from Flask to Pecan and it's working out great.</div><div class="gmail_extra"><br></div><div class="gmail_extra">With all that said, I don't want a version bump either for just a framework switch, as we just did v2 last release. v3 will be needed soon and once that happens, I'll already be ready with core API controllers I already switched over to Pecan.</div>
</div><div class="gmail_extra"><div><br></div><div><br>-Mike Perez</div>
</div></div>