Le 02/11/2016 12:26, Alex Xu a écrit :
2016-11-02 16:26 GMT+08:00 Sylvain Bauza <sba...@redhat.com
<mailto:sba...@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-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-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
