Open Stack

Looking at the backports, they are independent from one another and  I would say that these commits have no regression risk:
https://review.openstack.org/#/c/130097/2
https://review.openstack.org/#/c/130100/2

Functionally, they do not change and the differences are only inside the scope of the methods and only there they are used. 
They will be the easiest to approve, if they add a performance boost. (benchmarks needed).

Best regards,
Claudiu Belu
________________________________________
From: Claudiu Belu [cbelu at cloudbasesolutions.com]
Sent: Wednesday, October 29, 2014 3:24 PM
To: Ihar Hrachyshka; openstack-stable-maint at lists.openstack.org
Cc: kevinbenton at buttewifi.com
Subject: Re: [Openstack-stable-maint] Neutron backports for security group performance

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 at redhat.com]
Sent: Wednesday, October 29, 2014 3:09 PM
To: openstack-stable-maint at lists.openstack.org
Cc: kevinbenton at 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 at redhat.com <mailto:ihrachys at 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 at lists.openstack.org
> <mailto:Openstack-stable-maint at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>
>
>
>
>
> _______________________________________________
> Openstack-stable-maint mailing list
> Openstack-stable-maint at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint

_______________________________________________
Openstack-stable-maint mailing list
Openstack-stable-maint at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint