Open Stack

2017-04-15 4:38 GMT+08:00 Chet Burgess <cfb at metacloud.com>:

> On Fri, Apr 14, 2017 at 1:27 PM, Matt Riedemann <mriedemos at gmail.com>
> wrote:
>
>> The GET /servers/{server_id}/migrations API only lists in-progress live
>> migrations. This is an artifact of when it was originally introduced as the
>> os-migrations API which was tightly coupled with the API operation to
>> cancel a live migration.
>>
>> There is a spec [1] which is now approved which proposes to expand that
>> to also return other types of in-progress migrations, like cold migrations,
>> resizes and evacuations.
>>
>> What I don't like about the proposal is that it still filters out
>> completed migrations from being returned. I never liked the original design
>> where only in-progress live migrations would be returned. I understand why
>> it was done that way, as a convenience for using those results to then
>> cancel a live migration, but seriously that's something that can be
>> filtered out properly.
>>
>> So what I'd propose is that in a new microversion, we'd return all
>> migration records for a server, regardless of status. We could provide a
>> status filter query parameter if desired to just see in-progress
>> migrations, or completed migrations, etc. And the live migration cancel
>> action API would still validate that the requested migration to cancel is
>> indeed in progress first, else it's a 400 error.
>>
>> The actual migration entries in the response are quite detailed, so if
>> that's a problem, we could change listing to just show some short info (id,
>> status, source and target host), and then leave the actual details for the
>> show API.
>>
>> What do operators think about this? Is this used at all? Would you like
>> to get all migrations and not just in-progress migrations, with the ability
>> to filter as necessary?
>>
>> [1] https://review.openstack.org/#/c/407237/
>
>
> +1
>
> I would love to see this. Our support team frequently has to figure out
> the "history" of a VM and today they have to use tool that relies on logs
> and/or the DB to figure out where a VM used to be and when it was moved. It
> would wonderful if that whole tool can just be replaced with a single call
> to the nova API to return a full history.
>

Chet, do you have requirement to query the migrations for multiple VMs?
'/servers/{uuid}/migrations' will pain for that.

Also note that, we still have the API '/os-migrations', it will return all
the migration records in any status for all the VMs, and it supports
filters like 'instance_uuid', 'status', and 'migration_type' etc. I can't
remember clearly whether we said we will deprecated it, at least for now,
we didn't deprecate it yet. Want to figure whether it still have some
useful use-case for query multiple VMs' migration records.


>
> __________________________________________________________________________
> 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/20170417/c7cf7dbb/attachment.html>