<div dir="ltr">Hi Salvatore,<div> Please see my responses.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 11:03 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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">Hi Kumar,<div><br></div><div>some comments to your questions inline.</div><div>I am afraid I am unable to provide thorough answers. hopefully my thoughts will be beneficial at least to provide more context.</div>
<div><br></div><div>Salvatore<br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On 2 October 2013 19:04, Kumar <span dir="ltr"><<a href="mailto:chvsnrk@gmail.com" target="_blank">chvsnrk@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">Hi,<div> We are considering to run openstack Neutron in a large scale deployment. I would like to know community experience and suggestions.</div>
<div><br></div><div>To get to know the quality I am going through neutron bugs( I assume that is the best way to know the quality)</div>
<div>Some of them are real concerning like below bugs</div><div><a href="https://bugs.launchpad.net/neutron/+bug/1211915" target="_blank">https://bugs.launchpad.net/neutron/+bug/1211915</a><br></div><div><a href="https://bugs.launchpad.net/neutron/+bug/1230407" target="_blank">https://bugs.launchpad.net/neutron/+bug/1230407</a><br>
</div><div><a href="https://bugs.launchpad.net/neutron/+bug/1200001" target="_blank">https://bugs.launchpad.net/neutron/+bug/1200001</a><br></div><div><br></div><div>The bug 1211915 is raised for simple tempest tests,whats about huge deployments?</div>
<div>I am told even vendor neutron plugins too have similar issues when we create tens of instances in single click on horizon. And people see too many connection timeouts in quantum service logs with vendor plugins as well.</div>
<div><br></div></div></blockquote><div><br></div></div><div>Preamble: The aim of the next paragraph is not aimed at downplaying the issues on the gate.</div><div>During each release cycle, new features are added. In particular this time Neutron added VPN and Firewall services. This means that there is a lot of code churn, both on the neutron-server and python-neutronclient. Is not infrequent that critical bugs like the ones above (and you also left out bug 1240001) are in the code base up to a few days before the release. For vendor plugins, this might even be different, as they're not regulated by the same QA process as the plugin used by the gate (one might say it should not be like this - but this is probably out of the scope of this thread). I have to agree that during this release cycle Neutron has cause quite a few gate-blocking issues; on the other hand I don't think that flakiness during the release cycle is enough of a reason to label a project as "immature", "unstable", or "does not scale". <br>
</div></div></div></div></div></blockquote><div> </div><div>Kumar > I did get chance to meet folks using Vendor Plugins but they expressed the same concern. </div><div><br></div><div>Be it folsom, grizzly or Havana they have seen constant behavior issues either it could be tuning db connection poolsize etc., or neutron plugin so busy talking to its Openflow Controllers/quantum agents that it timeouts neutron client requests from nova.</div>
<div><br></div><div>I am with Neutron, pushing it and I am sure it brings in more flexibility in our deployments. I need the fuel to answer any questions. In production, where a small issue can cost us. So, we need to make a cautious step.</div>
<div><br></div><div>Most importantly, I have seen bugs proposed to fix in future versions and no backport onto old releases. This is a concern as deployments like us would not migrate to new releases as it consumes lot of time and effort to certify.</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><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>I was told that some were struck with nova-network as there is no support yet to migrate Neutron and they could not take advantage of new network services.<br>
</div></div></blockquote><div><br></div></div><div>This is correct. The migration process unfortunately is not easy, because you need to rearrange your cloud networking at different layers. I wish it was as easy as doing a db migration, but unfortunately it's nothing like that. I don't feel I have the authority and the competence to provide any migration advice, but in my opinion the current best bet is to provide parallel openstack installations with nova-network and neutron, and then progressively allocate new networks on the neutron installation until there are no more instances deployed on the nova-network installation. But please take the previous statement as nothing more than 'thinking aloud'.</div>
<div class="im">
<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>I would like to know community thinking on the same. Please note that I am not concerned on fix availability.</div>
<div><br></div></div></blockquote><div><br></div></div><div>From my side I can tell you that I am using on a daily basis an Openstack installation with a Neutron vendor plugin. We had our fair share of issues, but we're now fairly stable and happy performance wise on a Grizzly installation, and already working on the Havana upgrade. However, since I am one of the developers for said plugin, probably this doesn't count.</div>
<div>On the other hand, I've also been given a chance to test some production or beta Openstack clouds entirely based on opensource components; and I've been completely satisfied with the user experience; but my point of view here is limited again, because I don't have the perspective of the cloud admin in this case. </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></div><div>Thanks,</div><div>-Kumar</div><div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>