<div dir="ltr">Inline,<div>Salvatore<br><div class="gmail_extra"><br><div class="gmail_quote">On 12 October 2015 at 10:23, Germy Lure <span dir="ltr"><<a href="mailto:germy.lure@gmail.com" target="_blank">germy.lure@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you, Kevin.<div>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?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>In the case of Neutron and Nova, this is only done with REST over HTTP. Other projects also use RPC over AMQP.</div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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?</div></div></blockquote><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Germy</div><div>.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 11, 2015 at 4:33 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>I've tried out many N+1 combinations (e.g. Icehouse + Juno, Juno + Kilo) but I haven't tried a gap that big.</div><div><br></div><div>Cheers,</div><div>Kevin Benton</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Sat, Oct 10, 2015 at 1:50 AM, Germy Lure <span dir="ltr"><<a href="mailto:germy.lure@gmail.com" target="_blank">germy.lure@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi all,<div><br></div><div>As you know, openstack projects are developed separately. And theoretically, people can create networks with Neutron in Kilo version for Nova in Havana version.</div><div><br></div><div>Did Anyone tried it?</div><div>Do we have some pages to show what combination can work together?</div><div><br></div><div>Thanks.</div><div>Germy</div><div>.</div></div>
<br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div>Kevin Benton</div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>