Open Stack

Hi Salvatore,
Thank you so much.
I think I see your points now. Next step, I will have a try to check it.

Many thanks.
Germy
.


On Mon, Oct 12, 2015 at 11:11 PM, Salvatore Orlando <salv.orlando at gmail.com>
wrote:

> Inline,
> Salvatore
>
> On 12 October 2015 at 10:23, Germy Lure <germy.lure at gmail.com> wrote:
>
>> Thank you, Kevin.
>> So the community just divided the whole openstack into separate
>> sub-projects(Nova,Neutron and etc.) but it's not taken into account that if
>> those modules can work together with different versions. Yes?
>>
>
> The developer community has been addressing this by ensuring, to some
> extent, backward compatibility between the APIs used for communicating
> across services. This is what allows a component at version X to operate
> with another component at version Y.
>
> In the case of Neutron and Nova, this is only done with REST over HTTP.
> Other projects also use RPC over AMQP.
> Neutron strived to be backward compatible since the v2 API was introduced
> in Folsom. Therefore you should be able to run Neutron Kilo with Nova
> Havana; as Kevin noted, you might want to disable notifications on the
> Neutron side as the nova extension that processes them does not exist in
> Havana.
>
>
>
>>
>> If so, is it possible to keep being compatible with each other in
>> technology? How about just N+1? And how about just in Neutron?
>>
>
> While it is surely possible, enforcing this, as far as I can tell, is not
> a requirement for Openstack projects. Indeed, it is not something which is
> tested in the gate. It would be interesting to have it as a part of a
> rolling upgrade test for an OpenStack cloud, where, for instance, you first
> upgrade the networking service and then the compute service. But beyond
> that I do not think the upstream developer community should provide any
> additional guarantee, notwithstanding guarantees on API backward
> compatibility.
>
>
>> Germy
>> .
>>
>> On Sun, Oct 11, 2015 at 4:33 PM, Kevin Benton <blak111 at gmail.com> wrote:
>>
>>> For the particular Nova Neutron example, the Neutron Kilo API should
>>> still be compatible with the calls Havana Nova makes. I think you will need
>>> to disable the Nova callbacks on the Neutron side because the Havana
>>> version wasn't expecting them.
>>>
>>> I've tried out many N+1 combinations (e.g. Icehouse + Juno, Juno + Kilo)
>>> but I haven't tried a gap that big.
>>>
>>> Cheers,
>>> Kevin Benton
>>>
>>> On Sat, Oct 10, 2015 at 1:50 AM, Germy Lure <germy.lure at gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> As you know, openstack projects are developed separately. And
>>>> theoretically, people can create networks with Neutron in Kilo version for
>>>> Nova in Havana version.
>>>>
>>>> Did Anyone tried it?
>>>> Do we have some pages to show what combination can work together?
>>>>
>>>> Thanks.
>>>> Germy
>>>> .
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Kevin Benton
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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/20151014/535686ae/attachment.html>