[openstack-dev] Experiences of using Neutron in large scale

Salvatore Orlando sorlando at nicira.com
Wed Oct 2 18:03:12 UTC 2013


Hi Kumar,

some comments to your questions inline.
I am afraid I am unable to provide thorough answers. hopefully my thoughts
will be beneficial at least to provide more context.

Salvatore


On 2 October 2013 19:04, Kumar <chvsnrk at gmail.com> wrote:

> Hi,
>   We are considering to run openstack Neutron in a large scale deployment.
> I would like to know community experience and suggestions.
>
> To get to know the quality I am going through neutron bugs( I assume that
> is the best way to know the quality)
> Some of them are real concerning like below bugs
> https://bugs.launchpad.net/neutron/+bug/1211915
> https://bugs.launchpad.net/neutron/+bug/1230407
> https://bugs.launchpad.net/neutron/+bug/1200001
>
> The bug 1211915 is raised for simple tempest tests,whats about huge
> deployments?
> 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.
>
>
Preamble: The aim of the next paragraph is not aimed at downplaying the
issues on the gate.
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".


> 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.
>

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'.



> I would like to know community thinking on the same. Please note that I am
> not concerned on fix availability.
>
>
>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.
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.



> Thanks,
> -Kumar
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131002/0e1b186f/attachment.html>


More information about the OpenStack-dev mailing list