Open Stack

On Mon, Mar 16, 2015 at 6:06 PM, Ken'ichi Ohmichi <ken1ohmichi at gmail.com>
wrote:

> Hi Sean,
>
> 2015-03-16 23:15 GMT+09:00 Sean Dague <sean at dague.net>:
> > 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.
>
> Nice point, so the content of paste.ini seems what is our
> recommendation for API configuration.
>
> > 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.
>
> +1, the patch has been already posted.


> > 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).
>
> I'd like to propose /v1.1 removal.
> http://developer.openstack.org/api-ref.html also doesn't contain /v1.1
> endpoint.
> So the endpoint seems confusion for new users now.
>
>
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.


> > 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.
> >
> > 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.
> >
> > 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.
>
> +1 for "The full monty approach" instead of "The slow roll approach".
> Now the status of v2.1 API is CURRENT, and the one of v2 API is SUPPORTED.
> So I'd like to get feedback of v2.1 API as CURRENT API from users in Kilo.
>
> ++ to to the full Mont approach


>
> Thanks
> Ken Ohmichi
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150317/bc4c72f2/attachment.html>