Re: [openstack-dev] [Nova] Release criticality of bug 1365606 (get_network_info efficiency for nova-network)
and I don't see how https://review.openstack.org/#/c/121663/ is actually dependent on https://review.openstack.org/#/c/119521/. Yeah, agreed. I think that we _need_ the fix patch in Juno. The query optimization is good, and something we should take, but it makes me nervous sliding something like that in at the last minute without more exposure. Especially given that it has been like this for more than one release, it seems like Kilo material to me. --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Release criticality of bug 1365606 (get_network_info efficiency for nova-network)
On 9/25/2014 9:15 AM, Dan Smith wrote: and I don't see how https://review.openstack.org/#/c/121663/ is actually dependent on https://review.openstack.org/#/c/119521/. Yeah, agreed. I think that we _need_ the fix patch in Juno. The query optimization is good, and something we should take, but it makes me nervous sliding something like that in at the last minute without more exposure. Especially given that it has been like this for more than one release, it seems like Kilo material to me. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I agree with this and said the same in IRC a few times when it was brought up. Unfortunately the optimization patch was approved at one point but had to be rebased. Then about three weeks went by and we're sitting on top of rc1 and I think that optimization is too risky at this point, i.e. we have known gate issues, I wouldn't like to see us add to that. Granted, this might actually help with some gate races, I'm not sure, but it seems too risky to me without more time to back it in before we do release candidates. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Release criticality of bug 1365606 (get_network_info efficiency for nova-network)
To explain my rationale: I think it is totally reasonable to be conservative and wait to merge the actual fixes to the network calls[1][2] until Kilo and have them go through the stable/backports process. Unfortunately, due to our object design, if we block https://review.openstack.org/#/c/119521/ then there is no way we can backport those fixes, so we are stuck for a full 6 months with abysmal performance. This is why I’ve been pushing to get that one fix in. That said, I will happily decouple the two patches. Vish [1] https://review.openstack.org/#/c/119522/9 [2] https://review.openstack.org/#/c/119523/10 On Sep 24, 2014, at 3:51 PM, Michael Still mi...@stillhq.com wrote: Hi, so, I'd really like to see https://review.openstack.org/#/c/121663/ merged in rc1. That patch is approved right now. However, it depends on https://review.openstack.org/#/c/119521/, which is not approved. 119521 fixes a problem where we make five RPC calls per call to get_network_info, which is an obvious efficiency problem. Talking to Vish, who is the author of these patches, it sounds like the efficiency issue is a pretty big deal for users of nova-network and he'd like to see 119521 land in Juno. I think that means he's effectively arguing that the bug is release critical. On the other hand, its only a couple of days until rc1, so we're trying to be super conservative about what we land now in Juno. So... I'd like to see a bit of a conversation on what call we make here. Do we land 119521? Michael -- Rackspace Australia signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Release criticality of bug 1365606 (get_network_info efficiency for nova-network)
Ok new versions have reversed the order so we can take: https://review.openstack.org/#/c/121663/4 before: https://review.openstack.org/#/c/119521/10 I still strongly recommend that we take the second so we at least have the possibility of backporting the other two patches. And I also wouldn’t complain if we just took all 4 :) Vish On Sep 25, 2014, at 9:44 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: To explain my rationale: I think it is totally reasonable to be conservative and wait to merge the actual fixes to the network calls[1][2] until Kilo and have them go through the stable/backports process. Unfortunately, due to our object design, if we block https://review.openstack.org/#/c/119521/ then there is no way we can backport those fixes, so we are stuck for a full 6 months with abysmal performance. This is why I’ve been pushing to get that one fix in. That said, I will happily decouple the two patches. Vish [1] https://review.openstack.org/#/c/119522/9 [2] https://review.openstack.org/#/c/119523/10 On Sep 24, 2014, at 3:51 PM, Michael Still mi...@stillhq.com wrote: Hi, so, I'd really like to see https://review.openstack.org/#/c/121663/ merged in rc1. That patch is approved right now. However, it depends on https://review.openstack.org/#/c/119521/, which is not approved. 119521 fixes a problem where we make five RPC calls per call to get_network_info, which is an obvious efficiency problem. Talking to Vish, who is the author of these patches, it sounds like the efficiency issue is a pretty big deal for users of nova-network and he'd like to see 119521 land in Juno. I think that means he's effectively arguing that the bug is release critical. On the other hand, its only a couple of days until rc1, so we're trying to be super conservative about what we land now in Juno. So... I'd like to see a bit of a conversation on what call we make here. Do we land 119521? Michael -- Rackspace Australia signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Release criticality of bug 1365606 (get_network_info efficiency for nova-network)
On 09/24/2014 06:51 PM, Michael Still wrote: Hi, so, I'd really like to see https://review.openstack.org/#/c/121663/ merged in rc1. That patch is approved right now. However, it depends on https://review.openstack.org/#/c/119521/, which is not approved. 119521 fixes a problem where we make five RPC calls per call to get_network_info, which is an obvious efficiency problem. Talking to Vish, who is the author of these patches, it sounds like the efficiency issue is a pretty big deal for users of nova-network and he'd like to see 119521 land in Juno. I think that means he's effectively arguing that the bug is release critical. While I appreciate that there may be efficiency gains in https://review.openstack.org/#/c/119521/, these are not things that, AFAICT, were any different in Icehouse: http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py?id=2014.2.b3#n1362 and I don't see how https://review.openstack.org/#/c/121663/ is actually dependent on https://review.openstack.org/#/c/119521/. On the other hand, its only a couple of days until rc1, so we're trying to be super conservative about what we land now in Juno. So... I'd like to see a bit of a conversation on what call we make here. Do we land 119521? At the very least, I would say de-couple the two patches. Definitely merge 121663 and let 119521 bake a little bit would be my opinion. I've gone through 119521 three times now, and I don't see anything too obviously wrong with it. But then again, the DB queries in the nova-network codebase are generally pretty awkward, and I can't say for certain whether the joins added to nova.db.sqlalchemy.api.fixed_ip_get_by_instance() will speed up a few queries but end up slowing down a number of calls to that method that don't need the virtual_interface or floating_ips attributes of the Instance object. I'd personally like a few more hours tomorrow to go through the code. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
