Open Stack

On Mon, Mar 16, 2015 at 10:08 AM, John Garbutt <john at johngarbutt.com> wrote:
> On 16 March 2015 at 14:15, 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.
>
> +1
>
>> 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
>
> Lets drop the cruft now. People who feel they need it can add it back.
>
>> 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.
>
> If all the current popular SDKs can talk to v2.1 and v2 without
> noticing, then I think its likely to be fine to do this in general.
> Given my affiliation, this is the list I care about the most:
> https://developer.rackspace.com/sdks/

I'm on the team that takes care of those libraries so I'll ask what
the situation is for each of the projects.

This wouldn't be a problem for python-openstacksdk either. It
currently only has v2 but could just as easily and properly talk to
v{anything}.