<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 16, 2015 at 6:06 PM, Ken'ichi Ohmichi <span dir="ltr"><<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.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">Hi Sean,<br>
<span class=""><br>
2015-03-16 23:15 GMT+09:00 Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>>:<br>
> 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>
</span>Nice point, so the content of paste.ini seems what is our<br>
recommendation for API configuration.<br>
<span class=""><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>
</span>+1, the patch has been already posted. </blockquote><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">
<span class=""><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>
</span>I'd like to propose /v1.1 removal.<br>
<a href="http://developer.openstack.org/api-ref.html" target="_blank">http://developer.openstack.org/api-ref.html</a> also doesn't contain /v1.1 endpoint.<br>
So the endpoint seems confusion for new users now.<div><div class="h5"><br></div></div></blockquote><div><br></div><div>Maybe we should just comment out the /v1.1 stuff for now and remove it completely early in Lemming. That way if any new deployments need it for some strange reason its easy  to enable.</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"><div><div class="h5">
> 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>
> 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>
> 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>
<br>
</div></div>+1 for "The full monty approach" instead of "The slow roll approach".<br>
Now the status of v2.1 API is CURRENT, and the one of v2 API is SUPPORTED.<br>
So I'd like to get feedback of v2.1 API as CURRENT API from users in Kilo.<br><br></blockquote><div>++ to to the full Mont approach </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">
<br>
Thanks<br>
<span class=""><font color="#888888">Ken Ohmichi<br>
</font></span><div class=""><div class="h5"><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>
</div></div></blockquote></div><br></div></div>