Open Stack

On 04/10/2017 10:23 AM, Akihiro Motoki wrote:
> 2017-04-10 23:19 GMT+09:00 Dean Troyer <dtroyer at gmail.com>:
>> On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki <amotoki at gmail.com> wrote:
>>> (question not directly related to this topic)
>>> I am not sure there is a case where users still use API 2.36 for
>>> network management
>>> and newer API versions for other compute operation.
>>
>> This is probably true for Horizon, where the app install likely
>> matches the cloud it is configured to use.  However, many other use
>> cases for the Python libraries are meant to talk to multiple versions
>> of clouds and the 8.0 release of novaclient causes problems there.
>>
>> Even after nova-net support is EOL officially OSC plans to support the
>> use of nova-net for some time.  We are re-implementing the removed
>> functionality locally.  And anticipating some of the questions why,
>> consider an operator working on the long migration/upgrade from a
>> deployed nova-net cloud to a Neutron cloud, and needing to keep at
>> least one foot in both worlds.  There are other similar uses.
>
> This topic on novaclient 8.0.0 raised me a question on our python
> binding support policy.
> I see two points:
>
> - The one is which API version should be supported by a python binding
> from a same release.
> For example, Pike novaclient supports >2.36 of Nova API while Nova
> still supports <=2.35 API.
> Python bindings should support a whole set of supported API or a
> subset of supported API
> (of course including 'latest' version of API).

I think that because we use python-*client for intraservice 
communication, a release of a client needs to support the previous 
release (otherwise rolling upgrades can go poorly) I think given 
structure at this point trying to support more is a thing we should not 
bother doing and we should be clear about that.
>
> - The other is about multi cloud use cases. Different OpenStack clouds
> may use different releases
> and client libraries need to support
>
> The latter covers broader range of use cases.

If you are a user who wants to use multi-clouds - use shade. As an end 
user, trying to use our python client bindings directly for multi-cloud 
is very painful.