Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161102/b8d1d8a4/attachment.html>