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
__
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
