<div dir="ltr">Hi Sean-<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 16, 2015 at 11:15 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</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">Our current top level shipped example paste.ini for Nova includes the<br>
following set of endpoint definitions:<br>
<br>
[composite:osapi_compute]<br>
use = call:nova.api.openstack.urlmap:urlmap_factory<br>
/: oscomputeversions<br>
/v1.1: openstack_compute_api_v2<br>
/v2: openstack_compute_api_v2<br>
/v2.1: openstack_compute_api_v21<br>
/v3: openstack_compute_api_v3<br>
<br>
<br>
The real question I have is what should this look like in the Kilo<br>
release. And this has a couple of axes.<br>
<br>
Who uses our paste.ini?<br>
=========================<br>
<br>
paste.ini is an etc file, so we assume that during upgrade you'll be<br>
using your existing config. Changes to the default paste.ini will<br>
really only be effective in new deploys. So this should not impact<br>
existing users, but instead only new users.<br>
<br>
Cleaning up Cruft<br>
=================<br>
<br>
Drop of /v3<br>
-----------<br>
<br>
v3 is no longer a supported thing. I think v3 in the paste.ini causes<br>
confusion. It also causes us to keep around untested / unsupported<br>
code.<br>
<br>
This seems kind of a no brainer.<br>
<br>
Drop of /v1.1 ?<br>
---------------<br>
<br>
Only new deploys are really going to base off of our in tree<br>
config. I'm not convinced that we want to encourage people setting up<br>
new /v1.1 endpoint in tree.<br>
<br>
I'm not convinced there is a deprecation path here because the ones I<br>
could imagine would involve people changing their paste.ini to include<br>
a deprecation checking piece of code.<br>
<br>
Honestly, I don't care strongly either way on this one. It's cruft,<br>
but not dangerous cruft (unlike v3).<br>
<br></blockquote><div>+1</div><div> </div><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">
Nova v2<br>
=======<br>
<br>
This is where things get interesting.<br>
<br>
v2.1 is supposed to be equivalent to v2. The difference is moving the<br>
validation for datastructures from the database to the wsgi layer. The<br>
ways in which this doesn't react like the existing APIs should be<br>
basically not letting you create corrupt data models which will<br>
explode later in unexpected and hard to determine ways. The reality is<br>
objects validation has been sneaking this in all along anyway.<br>
<br>
The full monty approach<br>
-----------------------<br>
<br>
[composite:osapi_compute]<br>
use = call:nova.api.openstack.urlmap:urlmap_factory<br>
/: oscomputeversions<br>
/v1.1: openstack_compute_api_v2<br>
/v2: openstack_compute_api_v21<br>
# starting in Kilo the v21 implementation replaces the v2<br>
# implementation and is suggested that you use it as the default. If<br>
# this causes issues with your clients you can rollback to the<br>
# *frozen* v2 api by commenting out the above stanza and using the<br>
# following instead::<br>
# /v2: openstack_compute_api_v2<br>
# if rolling back to v2 fixes your issue please file a critical bug<br>
# at - <a href="https://bugs.launchpad.net/nova/+bugs" target="_blank">https://bugs.launchpad.net/nova/+bugs</a><br>
<br>
This would make the v2 endpoint the v21 implementation for new<br>
deploys. It would also make it easy for people to flip back if they<br>
hit an edge condition we didn't notice.<br>
<br></blockquote><div>+1. I think that will be the way to move forward with better APIs otherwise it will go in wait state for couple of cycles:).<br></div><div> </div><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">
In functional testing we'd still test both v2 and v2.1<br>
<br>
Tempest would move to v2.1 by default, and I think we should put an<br>
old v2 job on nova stable/kilo -> master to help us keep track of<br>
regressions.<br>
<br></blockquote><div>Patches are up to make v2.1 as default one in devstack (for gate jobs) - <a href="https://review.openstack.org/#/c/163731/">https://review.openstack.org/#/c/163731/</a> & <span style="color:rgb(0,0,0);font-size:9pt">Depends-On </span>patches.<br></div><div> </div><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">
The slow roll approach<br>
----------------------<br>
<br>
Ship the existing file (minus v3):<br>
<br>
[composite:osapi_compute]<br>
use = call:nova.api.openstack.urlmap:urlmap_factory<br>
/: oscomputeversions<br>
/v1.1: openstack_compute_api_v2<br>
/v2: openstack_compute_api_v2<br>
/v2.1: openstack_compute_api_v21<br>
<br>
The advantages here is that out of the box stuff keeps working. The<br>
dilema here is it's not really clear that we'll get people poking at<br>
v2.1 because it will be out of the main path. The point of the<br>
microversioning was to get folks onto that train soon because it falls<br>
back to existing API. And once we are convinced we're good we can<br>
deprecate out the old implementation.<br>
<br>
Also, things like out of tree EC2 support requires v2.1, which is<br>
going to make deploys start relying on a /v2.1 endpoint that want EC2,<br>
so our options for grafting that back onto /v2 in the future are more<br>
limitted.<br>
<br>
Decision Time<br>
=============<br>
<br>
Anyway, this is a decision we should make before freeze. The 'no<br>
decision' case gives us the slow roll. I think from an upstream<br>
perspective the full monty will probably serve us a little<br>
better. Especially with robust release notes that explain to people<br>
how to move their endpoints forward.<br>
<span class=""><font color="#888888"><br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Thanks & Regards</div><div>Ghanshyam Mann</div><div><br></div></div></div>
</div></div>