| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 17:47:17 | mriedem | cfriesen: so we should be pulling migrations per server /servers/{uuid}/migrations | |
| 17:48:20 | mriedem | cfriesen: would have to look at what nova migration-list does, because i thought it would take a server uuid | |
| 17:48:42 | mriedem | ah | |
| 17:48:43 | mriedem | https://docs.openstack.org/cli-reference/nova.html#nova-server-migration-list | |
| 17:48:53 | mriedem | cfriesen: ^ | |
| 17:49:01 | mriedem | that will return the list of live migrations for the given server | |
| 17:49:09 | mriedem | if you have a high enough api to provide that microversion | |
| 17:52:47 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell in conductor cold migrate https://review.openstack.org/438022 | |
| 17:52:48 | openstackgerrit | Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023 | |
| 17:52:48 | openstackgerrit | Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024 | |
| 17:52:49 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025 | |
| 17:53:54 | dansmith | no whammies no whammies no whammies | |
| 18:00:33 | cfriesen | mriedem: okay, server-migration-list is useful. still requires parsing though. would it maybe make sense to have a "--active" flag on that to return just the in-progress migration for that server? | |
| 18:02:08 | cfriesen | or do we just make client code sort the response by ID and pick the latest to try to get the active one? | |
| 18:03:20 | mriedem | cfriesen: it might be nice to add a status filter query parameter to the /servers/id/migrations REST API | |
| 18:03:27 | mriedem | we could validate that with json schema now | |
| 18:04:37 | mriedem | cfriesen: but it does look like you could filter client side | |
| 18:04:40 | mriedem | we print out the migration status | |
| 18:07:57 | cfriesen | mriedem: hmm...in newton at least it appears that "server-migration-list" doesn't show completed migrations | |
| 18:10:36 | mriedem | cfriesen: that's because it's calling objects.MigrationList.get_in_progress_by_instance | |
| 18:11:01 | mriedem | where in-progress is one of | |
| 18:11:02 | mriedem | 'queued', 'preparing', | |
| 18:11:02 | mriedem | 'running', | |
| 18:11:02 | mriedem | 'post-migrating'] | |
| 18:11:12 | mriedem | why we only return in progress migrations, idk | |
| 18:11:22 | mriedem | i think because that api was added for being able to cancel a live migration | |
| 18:11:28 | mriedem | which you can only do if it's running | |
| 18:11:35 | mriedem | tdurakov might remember more | |
| 18:12:09 | mriedem | cfriesen: so before you ask "why only in progress live migrations?" i think that's the original idea of why, but "can we return all, not just in progress?" - i'd think sure | |
| 18:13:00 | mriedem | i believe the os-migrations API returns all migrations | |
| 18:13:40 | mriedem | imo it's a pretty clunky gd API and is tailor made just for canceling a live migration | |
| 18:13:48 | mriedem | which seemed to be too short sighted | |
| 18:14:34 | cfriesen | mriedem: hmm...the API docs do specify that it's in-progress live migrations, but the CLI docs don't specify that it's only for in-progress migrations. | |
| 18:15:14 | tdurakov | It was done to return adress live-mig abort functionality | |
| 18:17:28 | cfriesen | tdurakov: okay, thanks. I agree it's a bit clunky, but it does at least let you get the info needed to abort. | |
| 18:18:44 | cfriesen | mriedem: tdurakov: is it just me that thinks "nova server-migration-list" is a wierd command for something that should only ever have a single result? | |
| 18:21:09 | mriedem | cfriesen: i believe i wrote the api ref docs because they didn't exist | |
| 18:21:17 | mriedem | and i was sorting this all out about 5 months ago | |
| 18:21:26 | tdurakov | Migration list is awful... | |
| 18:23:37 | mriedem | cfriesen: you could push a patch to update the cli help | |
| 18:23:42 | mriedem | to make it more clear | |
| 19:19:07 | openstackgerrit | Monty Taylor proposed openstack/nova master: WIP Clean up and consolidate client creation https://review.openstack.org/438512 | |
| 19:19:07 | openstackgerrit | Monty Taylor proposed openstack/nova master: Be a little more explicit about checking ok status https://review.openstack.org/439121 | |
| 19:32:00 | openstackgerrit | Sujitha proposed openstack/nova master: Remove mox from nova/tests/unit/db/test_db_api.py https://review.openstack.org/434557 | |
| 19:45:57 | tdurakov | mriedem: I wonder what if we just merge these 2 comands from the client side, I mean ,nova migration-list and nove server-migration-list | |
| 19:47:31 | mriedem | tdurakov: as in like nova migration-list --server <optional server id> which toggles the behavior, i.e. which REST API to call? | |
| 19:48:04 | tdurakov | afair there is no --server param in nova migration list | |
| 19:48:10 | mriedem | there isn't | |
| 19:48:14 | mriedem | but that's how i'd unify the CLIs | |
| 19:48:20 | tdurakov | yeah | |
| 19:48:28 | tdurakov | sounds good! | |
| 19:49:26 | tdurakov | once takashi implement the spec, it will be more useful | |
| 19:51:24 | mriedem | it is a bit odd, the os-migrations API behaves differently depending on if you're using >=2.23 | |
| 19:52:01 | mriedem | 2.23+ will add links to servers for in-progress live migrations | |
| 19:52:13 | mriedem | 2.23+ will always return the migration_type | |
| 19:52:39 | mriedem | and os-migrations doesn't filter on just live migrations | |
| 19:52:47 | mriedem | so it can also return cold migrations and evacuations | |
| 19:53:00 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025 | |
| 19:53:04 | mriedem | /servers/uuid/migrations will only return in-progress live migrations | |
| 19:53:54 | mriedem | we are definitely missing some behavioral details in the api-ref for os-migrations https://developer.openstack.org/api-ref/compute/?expanded=list-migrations-detail#list-migrations | |
| 19:55:23 | tdurakov | right, but the problem with the link, that is passed after 2.23 is already there | |
| 19:56:23 | mriedem | i'm not sure i understand your point | |
| 19:56:43 | mriedem | os-migrations will return the links for 2.23+, and we also have /servers/id/migrations at 2.23 | |
| 19:56:47 | mriedem | so yes it's redundant | |
| 19:56:59 | mriedem | i believe that's why os-migrations is marked as "frozen" | |
| 19:57:06 | mriedem | although the APIs do behave differently | |
| 19:57:13 | mriedem | so it's kind of odd that os-migrations is frozen | |
| 19:57:28 | mriedem | it seems to be frozen for a very specific case, which is the in-progress live migration case so you can cancel those things | |
| 19:57:38 | tdurakov | my current understanding of the problem: I'd like to see /servers/uuid/migrations become more useful(not only live-migrations) and maybe not only active, based on that I think it's worth to have a mechanism to filter migrations not only by instnace, but host and cell as well | |
| 19:57:46 | mriedem | but if i'm an admin and i just want to see any migration, including completed ones, i can't use /servers/id/migrations | |
| 19:58:40 | mriedem | i don't even see where os-migrations filters by cell | |
| 19:59:13 | tdurakov | mriedem: http://paste.openstack.org/show/600833/ | |
| 19:59:30 | mriedem | tdurakov: in general yes, i think if /servers/id/migrations replaces os-migrations, then the former needs to be built up to serve the needs that the latter already provideds | |
| 19:59:34 | mriedem | *provided | |
| 19:59:39 | tdurakov | is doc help doc misleading? | |
| 19:59:44 | mriedem | i think so | |
| 19:59:51 | mriedem | i don't see anything in the db api code about filtering migrations by cell name | |
| 20:01:05 | tdurakov | at the same point it would be weird to filter out migration by host at the uri: /servers/id/migrations because it's about servers, righht? | |
| 20:01:10 | mriedem | yeah cell_name is passed as a query parameter | |
| 20:01:16 | mriedem | correct | |
| 20:01:31 | mriedem | so the GET query parameters are passed way down to migration_get_all_by_filters in the db api | |
| 20:01:38 | mriedem | and cell_name isn't a thing that gets filtered on | |
| 20:01:42 | mriedem | so the CLI code is lying to us | |
| 20:01:43 | mriedem | :) | |
| 20:02:14 | mriedem | cell_name is not even in the migrations table | |
| 20:02:22 | mriedem | so i don't know who thought that up | |
| 20:07:19 | mriedem | https://github.com/openstack/python-novaclient/commit/3c2a817efcb6954f3c8246c32ce997b9e3a4d000 | |
| 20:07:23 | mriedem | cell_name was just always there | |
| 20:07:39 | mriedem | crazy ass rax | |
| 20:07:44 | mriedem | i'll remove that from novaclient | |
| 20:11:02 | mriedem | this will allow me to procrastinate on recapping the resource provider talk from the PTG, which i didn't follow most of i don't think | |
| 20:11:26 | mriedem | something something traits ironic inventory success glory fame | |
| 20:11:33 | mriedem | jaypipes: ^ is that the summary from the PTG? | |
| 20:13:48 | mriedem | sdague: i suppose to be a nice guy, i should deprecate a completely worthless and unused CLI arg/python API binding option in novaclient for a release before removing it right? | |
| 20:13:55 | mriedem | even though it's never ever worked | |
| 20:15:13 | tdurakov | mriedem: patch is in progress | |
| 20:15:26 | mriedem | tdurakov: are you deprecating or removing? | |
| 20:15:28 | mriedem | also https://bugs.launchpad.net/python-novaclient/+bug/1668743 | |
| 20:15:28 | openstack | Launchpad bug 1668743 in python-novaclient "nova migration-list --cell_name does not actually do anything" [Undecided,New] - Assigned to Matt Riedemann (mriedem) | |
| 20:15:31 | tdurakov | no reason procrastinating on resource provider | |