Open Stack

The proposal looks reasonable.

This could greatly help operation team if a migration no longer
vanishes from the API once completed.
Can I assume some form of advanced filtering will be proposed to
ensure an instance doesn't end up with 1k records?
One suggestion would be filtering by date or limiting the number of
records returned.

On Fri, Apr 14, 2017 at 4: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/
>
> --
>
> Thanks,
>
> Matt
>