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

Attachment: 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

Reply via email to