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
