Open Stack

Hi Sean-

On Mon, Mar 16, 2015 at 11:15 PM, Sean Dague <sean at dague.net> wrote:

> Our current top level shipped example paste.ini for Nova includes the
> following set of endpoint definitions:
>
> [composite:osapi_compute]
> use = call:nova.api.openstack.urlmap:urlmap_factory
> /: oscomputeversions
> /v1.1: openstack_compute_api_v2
> /v2: openstack_compute_api_v2
> /v2.1: openstack_compute_api_v21
> /v3: openstack_compute_api_v3
>
>
> The real question I have is what should this look like in the Kilo
> release. And this has a couple of axes.
>
>  Who uses our paste.ini?
> =========================
>
> paste.ini is an etc file, so we assume that during upgrade you'll be
> using your existing config. Changes to the default paste.ini will
> really only be effective in new deploys. So this should not impact
> existing users, but instead only new users.
>
> Cleaning up Cruft
> =================
>
> Drop of /v3
> -----------
>
> v3 is no longer a supported thing. I think v3 in the paste.ini causes
> confusion. It also causes us to keep around untested / unsupported
> code.
>
> This seems kind of a no brainer.
>
> Drop of /v1.1 ?
> ---------------
>
> Only new deploys are really going to base off of our in tree
> config. I'm not convinced that we want to encourage people setting up
> new /v1.1 endpoint in tree.
>
> I'm not convinced there is a deprecation path here because the ones I
> could imagine would involve people changing their paste.ini to include
> a deprecation checking piece of code.
>
> Honestly, I don't care strongly either way on this one. It's cruft,
> but not dangerous cruft (unlike v3).
>
> +1


> Nova v2
> =======
>
> This is where things get interesting.
>
> v2.1 is supposed to be equivalent to v2. The difference is moving the
> validation for datastructures from the database to the wsgi layer. The
> ways in which this doesn't react like the existing APIs should be
> basically not letting you create corrupt data models which will
> explode later in unexpected and hard to determine ways. The reality is
> objects validation has been sneaking this in all along anyway.
>
> The full monty approach
> -----------------------
>
> [composite:osapi_compute]
> use = call:nova.api.openstack.urlmap:urlmap_factory
> /: oscomputeversions
> /v1.1: openstack_compute_api_v2
> /v2: openstack_compute_api_v21
> # starting in Kilo the v21 implementation replaces the v2
> # implementation and is suggested that you use it as the default. If
> # this causes issues with your clients you can rollback to the
> # *frozen* v2 api by commenting out the above stanza and using the
> # following instead::
> # /v2: openstack_compute_api_v2
> # if rolling back to v2 fixes your issue please file a critical bug
> # at - https://bugs.launchpad.net/nova/+bugs
>
> This would make the v2 endpoint the v21 implementation for new
> deploys. It would also make it easy for people to flip back if they
> hit an edge condition we didn't notice.
>
> +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:).


> In functional testing we'd still test both v2 and v2.1
>
> Tempest would move to v2.1 by default, and I think we should put an
> old v2 job on nova stable/kilo -> master to help us keep track of
> regressions.
>
> Patches are up to make v2.1 as default one in devstack (for gate jobs) -
https://review.openstack.org/#/c/163731/ & Depends-On patches.


> The slow roll approach
> ----------------------
>
> Ship the existing file (minus v3):
>
> [composite:osapi_compute]
> use = call:nova.api.openstack.urlmap:urlmap_factory
> /: oscomputeversions
> /v1.1: openstack_compute_api_v2
> /v2: openstack_compute_api_v2
> /v2.1: openstack_compute_api_v21
>
> The advantages here is that out of the box stuff keeps working. The
> dilema here is it's not really clear that we'll get people poking at
> v2.1 because it will be out of the main path. The point of the
> microversioning was to get folks onto that train soon because it falls
> back to existing API. And once we are convinced we're good we can
> deprecate out the old implementation.
>
> Also, things like out of tree EC2 support requires v2.1, which is
> going to make deploys start relying on a /v2.1 endpoint that want EC2,
> so our options for grafting that back onto /v2 in the future are more
> limitted.
>
> Decision Time
> =============
>
> Anyway, this is a decision we should make before freeze. The 'no
> decision' case gives us the slow roll. I think from an upstream
> perspective the full monty will probably serve us a little
> better. Especially with robust release notes that explain to people
> how to move their endpoints forward.
>
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150317/b53fb236/attachment.html>