Le 01/11/2016 15:14, Alex Xu a écrit :
Currently we only update the resource usage with Placement API in the
instance claim and the available resource update periodic task. But
there is no claim for migration with placement API yet. This works is
tracked by https://bugs.launchpad.net/nova/+bug/1621709. In newton, we
only fix one bit which make the resource update periodic task works
correctly, then it will auto-heal everything. For the migration claim
part, that isn't the goal for newton release.
To be clear, there are two distinct points :
#1 there are MoveClaim objects that are synchronously made on resize
(and cold-migrate) and rebuild (and evacuate), but there is no claim
done by the live-migration path.
There is a long-standing bugfix https://review.openstack.org/#/c/244489/
that's been tracked by https://bugs.launchpad.net/nova/+bug/1289064
#2 all those claim operations don't trigger an allocation request to the
placement API, while the regular boot operation does (hence your bug
report).
So the first question is do we want to fix it in this release? If the
answer is yes, there have a concern need to discuss.
I'd appreciate if we could merge first #1 before #2 because the
placement API decisions could be wrong if we decide to only allocate for
certain move operations.
In order to implement the drop of migration claim, the RT needs to
remove allocation records on the specific RP(on the source/destination
compute node). But there isn't any API can do that. The API about
remove allocation records is 'DELETE /allocations/{consumer_uuid}',
but it will delete all the allocation records for the consumer. So the
initial fix(https://review.openstack.org/#/c/369172/) adds new API
'DELETE /resource_providers/{rp_uuid}/allocations/{consumer_id}'. But
Chris Dent pointed out this against the original design. All the
allocations for the specific consumer only can be dropped together.
There also have suggestion from Andrew, we can update all the
allocation records for the consumer each time. That means the RT will
build the original allocation records and new allocation records for
the claim together, and put into one API. That API should be 'PUT
/allocations/{consumer_uuid}'. Unfortunately that API doesn't replace
all the allocation records for the consumer, it always amends the new
allocation records for the consumer.
So which directly we should go at here?
Thanks
Alex
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
