<div dir="ltr">Hi Miguel,<div><br></div><div>while we'd need to hear from the stable team, I think it's not such a bad idea to make this tool available to users of pre-juno openstack releases.</div><div>As far as upstream repos are concerned, I don't know if this tool violates the criteria for stable branches. Even if it would be a rather large change for stable/icehouse, it is pretty much orthogonal to the existing code, so it could be ok. However, please note that stable/havana has now reached its EOL, so there will be no more stable release for it.</div><div><br></div><div>The orthogonal nature of this tool however also make the case for making it widely available on pypi. I think it should be ok to describe the scalability issue in the official OpenStack Icehouse docs and point out to this tool for mitigation.</div><div><br></div><div>Salvatore </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 October 2014 14:03, Miguel Angel Ajo Pelayo <span dir="ltr"><<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Recently, we have identified clients with problems due to the<br>
bad scalability of security groups in Havana and Icehouse, that<br>
was addressed during juno here [1] [2]<br>
<br>
This situation is identified by blinking agents (going UP/DOWN),<br>
high AMQP load, nigh neutron-server load, and timeout from openvswitch<br>
agents when trying to contact neutron-server "security_group_rules_for_devices".<br>
<br>
Doing a [1] backport involves many dependent patches related<br>
to the general RPC refactor in neutron (which modifies all plugins),<br>
and subsequent ones fixing a few bugs. Sounds risky to me. [2] Introduces<br>
new features and it's dependent on features which aren't available on<br>
all systems.<br>
<br>
To remediate this on production systems, I wrote a quick tool<br>
to help on reporting security groups and mitigating the problem<br>
by writing almost-equivalent rules [3].<br>
<br>
We believe this tool would be better available to the wider community,<br>
and under better review and testing, and, since it doesn't modify any behavior<br>
or actual code in neutron, I'd like to propose it for inclusion into, at least,<br>
Icehouse stable branch where it's more relevant.<br>
<br>
I know the usual way is to go master->Juno->Icehouse, but at this moment<br>
the tool is only interesting for Icehouse (and Havana), although I believe<br>
it could be extended to cleanup orphaned resources, or any other cleanup<br>
tasks, in that case it could make sense to be available for K->J->I.<br>
<br>
As a reference, I'm leaving links to outputs from the tool [4][5]<br>
<br>
Looking forward to get some feedback,<br>
Miguel Ángel.<br>
<br>
<br>
[1] <a href="https://review.openstack.org/#/c/111876/" target="_blank">https://review.openstack.org/#/c/111876/</a> security group rpc refactor<br>
[2] <a href="https://review.openstack.org/#/c/111877/" target="_blank">https://review.openstack.org/#/c/111877/</a> ipset support<br>
[3] <a href="https://github.com/mangelajo/neutrontool" target="_blank">https://github.com/mangelajo/neutrontool</a><br>
[4] <a href="http://paste.openstack.org/show/123519/" target="_blank">http://paste.openstack.org/show/123519/</a><br>
[5] <a href="http://paste.openstack.org/show/123525/" target="_blank">http://paste.openstack.org/show/123525/</a><br>
<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>
</blockquote></div><br></div>