Open Stack

Le 02/11/2016 12:26, Alex Xu a écrit :
>
>
> 2016-11-02 16:26 GMT+08:00 Sylvain Bauza <sbauza at redhat.com 
> <mailto:sbauza at redhat.com>>:
>
>
>
>     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
>>     <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/
>     <https://review.openstack.org/#/c/244489/> that's been tracked by
>     https://bugs.launchpad.net/nova/+bug/1289064
>     <https://bugs.launchpad.net/nova/+bug/1289064>
>
>
> Yea, thanks for the info. I say `migration claim` is more about the 
> move claim. Maybe I should say the move claim.
>
>

Np, just a clarification for all of us, not you in particular :-)

>
>     #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).
>
>
> Yes, except the booting new instance, other claims won't trigger 
> allocation request to the placement API.

Oops, I badly wrote my prose in English, I meant your point, ie. that we 
only write allocation requests for boot operations, and not for move 
operations.
>
>
>
>
>>
>>     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.
>
>
> Sorry, I didn't get you, what is 'the placement API decisions' pointed to?

I personnally think that rather writing allocation records for all move 
operations but the live-migration case, we should first have the move 
operations being consistent by doing claim operations and only that 
being done, consider writing those allocation records to the placement API.

-Sylvain

>
>
>>     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/
>>     <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  <mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> __________________________________________________________________________
> 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/5a83b358/attachment.html>