Thanks Giblet,
Will review this afternoon.
Best,
-jay
On 09/17/2018 09:10 AM, Balázs Gibizer wrote:
Hi,
Reworked and rebased the series based on this thread. The series starts
here https://review.openstack.org/#/c/591597
Cheers,
gibi
Hi,
Reworked and rebased the series based on this thread. The series starts
here https://review.openstack.org/#/c/591597
Cheers,
gibi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
On 08/22/2018 08:55 AM, Balázs Gibizer wrote:
On Fri, Aug 17, 2018 at 5:40 PM, Eric Fried wrote:
gibi-
- On migration, when we transfer the allocations in either
direction, a
conflict means someone managed to resize (or otherwise change
allocations?) since the last time we pulled data.
Sorry for the delay in responding to this, Gibi and Eric. Comments inline.
tl;dr: go with option a)
On 08/16/2018 11:34 AM, Eric Fried wrote:
Thanks for this, gibi.
TL;DR: a).
I didn't look, but I'm pretty sure we're not caching allocations in the
report client. Today, nobody outside of nova
b) sounds the most sane in both cases. I don't like the idea of "your
move operation failed and you have no recourse but to delete your
instance". And automatic retry sounds lovely, but potentially hairy to
implement (and we would need to account for the retries-failed scenario
anyway) so at least
On Fri, Aug 17, 2018 at 5:40 PM, Eric Fried wrote:
gibi-
- On migration, when we transfer the allocations in either
direction, a
conflict means someone managed to resize (or otherwise change
allocations?) since the last time we pulled data. Given the global
lock
in the report client,
gibi-
>> - On migration, when we transfer the allocations in either direction, a
>> conflict means someone managed to resize (or otherwise change
>> allocations?) since the last time we pulled data. Given the global lock
>> in the report client, this should have been tough to do. If it does
>>
On Thu, Aug 16, 2018 at 5:34 PM, Eric Fried wrote:
Thanks for this, gibi.
TL;DR: a).
I didn't look, but I'm pretty sure we're not caching allocations in
the
report client. Today, nobody outside of nova (specifically the
resource
tracker via the report client) is supposed to be mucking
Thanks for this, gibi.
TL;DR: a).
I didn't look, but I'm pretty sure we're not caching allocations in the
report client. Today, nobody outside of nova (specifically the resource
tracker via the report client) is supposed to be mucking with instance
allocations, right? And given the global lock
reformatted for readabiliy, sorry:
Hi,
tl;dr: To properly use consumer generation (placement 1.28) in Nova we
need to decide how to handle consumer generation conflict from Nova
perspective:
a) Nova reads the current consumer_generation before the allocation
update operation and use that
10 matches
Mail list logo
