Open Stack

On 04/14/2017 04:27 PM, Matt Riedemann 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/

For clarification, part of the reason that this only shows in progress 
things is because of instance_actions. It was assumed that if people 
wanted to know what happened in the past, they'd use that mechanism 
instead, this was only about live things.

That might be a faulty assumption, it might be there there is missing 
information in instance actions, or that the policy access isn't right 
for a set of users. But it would be good to be explicit about what's 
wrong with instance actions for the original assumption (that past 
events should only be exposed there) to not be true. Or if there should 
be more of a concerned push to polish the instance_actions API.

	-Sean

-- 
Sean Dague
http://dague.net