1. Miguel: Ideally, yes, it should be enough to validate the backports. But most of the CIs will run a subset of the tempest tests that may or may not include tempest.scenario.test_security_groups_basic_ops, which tests the functionality of the security groups on the compute nodes. But this would be a problem on master too.. 2. Dolph: good point, a benchmark is appropriate in this scenario. It will help us decide whether the backports are worth the risk they have or not. I also agree with the fact that low enough performance is a kind of bug. 3. Thierry: I agree, those backports have a risk of regression, but low performance is a problem too. We should at least see the benchmark results and then decide whether the gain significantly outweighs the risk or not. :) ________________________________________ From: Ihar Hrachyshka [ihrachys@redhat.com] Sent: Wednesday, October 29, 2014 3:09 PM To: openstack-stable-maint@lists.openstack.org Cc: kevinbenton@buttewifi.com Subject: Re: [Openstack-stable-maint] Neutron backports for security group performance -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 29/10/14 14:00, Dolph Mathews wrote:
On Wed, Oct 29, 2014 at 5:23 AM, Ihar Hrachyshka <ihrachys@redhat.com <mailto:ihrachys@redhat.com>> wrote:
Hi all,
there is a series of Neutron backports in the Juno queue that are intended to significantly improve service performance when handling security groups (one of the issues that are main pain points of current users):
- https://review.openstack.org/130101 - https://review.openstack.org/130098 - https://review.openstack.org/130100 - https://review.openstack.org/130097 - https://review.openstack.org/130105
The first four patches are optimizing db side (controller), while the last one is to avoid fetching security group rules by OVS agent when firewall is disabled.
AFAIK we don't generally backport performance improvements unless they are very significant (though I don't see anything written in stone that says so), but knowing that those patches fix pain hotspots in Neutron, and seem rather isolated, should we consider their inclusion?
Should we come up with some "official" rule on how we handle performance enhancement backports?
I'm very much in favor of backporting known performance improvements, but in my experience, not all "performance improvements" actually improve performance, so I'd expect an appropriate benchmark to demonstrate a real performance benefit to coincide with the proposed patch.
Exactly. That's what I asked to elaborate on at: https://review.openstack.org/#/c/130101/ Also, adding Kevin into CC to make sure he is aware of the discussion.
For a hypothetical example, what seems like a clear cut improvement in review 130098 (remove unused columns from a query) *might* have an unforeseen side effect later on, where another component doesn't have the data it needs, so it suddenly starts issuing a new DB query to compensate. OpenStack is certainly complicated enough that it's impossible to make accurate assumptions about performance.
/Ihar
_______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org <mailto:Openstack-stable-maint@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
_______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUUObtAAoJEC5aWaUY1u57UYwH/j+wjiydOXjA+lFi3l1Pbl5f s7r4Ox6FCPPVoAKziKpygKRbHTrCTew4DcgOxZhmC9qoq+Rk8Q1WFMLlBQ+51Kjj lj/72JiPenKvuZSl/E+9FsmWP7ReCCyUMYWiQS6wp6FAd5KpQMMgdjleUQWEAgjN Y1M9kYVOmqnYHQy4oWJsV0Od2wFKFAGDKohLEzDocmTQFxcfkEeMSn3qJ4aOwkoz KmTFKPGAGU8eTyYNAs3sHa0t9VFwvPoBg4EjMXBjkuoRxz+Nf/IPUZmrruXQ7LM6 ioXEUH3GdKQSCKWtYoFFI1QPpiTQSIalO6nURxUg0UldW6i5QwIX1LTz8GMG+TQ= =JJq0 -----END PGP SIGNATURE----- _______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint