Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170414/f4271491/attachment.html>