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