| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-27 | |||
| 16:58:29 | melwitt | the first time I read it, I thought the documentation was a mistake. but edleafe confirmed that it is indeed supposed to be "consumer" uuid | |
| 16:58:49 | mriedem | probably should have been "openstack resource allocation list <consumer_uuid>" | |
| 16:59:36 | mriedem | could still add that and deprecate the old command | |
| 17:02:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Cross-cell resize https://review.openstack.org/603930 | |
| 17:15:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix stacktraces with redis caching backend https://review.openstack.org/605748 | |
| 17:22:54 | mnaser | openstackclient doesnt let you do a live migration unless you specify a host? | |
| 17:23:29 | mnaser | https://github.com/openstack/python-openstackclient/blob/c0567806916995698e94734d2b2c422a4bf5a1db/openstackclient/compute/v2/server.py#L1333-L1337 | |
| 17:23:43 | nicolasbock | Thanks mriedem and melwitt . Yes, the wording could be clearer, but then again I probabaly could have read the help a little bit more carefully :) | |
| 17:23:58 | nicolasbock | I think that's true mnaser | |
| 17:24:16 | mnaser | nova can do live migrations without specifying a host | |
| 17:24:19 | mnaser | the novaclient lets you do it | |
| 17:24:32 | mnaser | and i think there's been voices of "forcing a host in migrations is a bad idea™" | |
| 17:25:41 | nicolasbock | But in 'nova live-migration' you also need to specify a host | |
| 17:25:49 | nicolasbock | Same as in 'openstack server migrate' | |
| 17:25:55 | cfriesen | mnaser: yeah, it's messed up | |
| 17:26:02 | nicolasbock | sorry 'openstack server migrate --live' | |
| 17:26:05 | mnaser | nova live-migration does not require a host | |
| 17:26:09 | cfriesen | mnaser: migration and live migration in OSC need help | |
| 17:26:11 | mnaser | it is optional | |
| 17:26:13 | melwitt | yeah, there are unfortunate discrepancies between novaclient and openstackclient. we talked about it a bit at the PTG L721 https://etherpad.openstack.org/p/nova-ptg-stein | |
| 17:26:47 | mnaser | i guess this is a lot harder than expected because we'd break "api" | |
| 17:26:55 | mnaser | im not sure what'd be the ideal solution | |
| 17:27:30 | melwitt | I was thinking we could just "fix" the openstackclient side to be able to do the same stuff as novaclient. just someone has to do it | |
| 17:27:48 | mnaser | hmm im thinking add a positional argument [host] | |
| 17:27:52 | melwitt | would have to talk to dtroyer about it more | |
| 17:27:58 | mnaser | and make osc ignore the parameter provided to --live | |
| 17:28:08 | mnaser | at least to let you do clean live migrations | |
| 17:28:57 | cfriesen | mnaser: while you're in there you could also fix up all the *other* live-migration related stuff that OSC doesn't handle. | |
| 17:29:16 | cfriesen | automatic detection of block/shared, for example | |
| 17:29:34 | melwitt | oh yep, that's one that our customers have hit many times | |
| 17:29:36 | artom | Careful about that though, they're moving to openstacksdk, so it might be more intelligent to just help with the move | |
| 17:29:44 | artom | (Assuming openstacksdk doesn't have the same problems) | |
| 17:30:24 | artom | (Can I just say that I feel like like the *clients, then openstackclient, then openstacksdk is a case of https://xkcd.com/927/ ) | |
| 17:30:59 | melwitt | moving to openstacksdk is going to change the CLI arguments? I haven't read in detail about what that will involve | |
| 17:30:59 | mnaser | yep | |
| 17:31:12 | mnaser | openstacksdk has some 'intelligence' | |
| 17:31:17 | mnaser | inherited from shade | |
| 17:31:24 | mnaser | so it does a lot of figuring out of the right thing to do | |
| 17:31:32 | mnaser | or the ideal set of defaults so to speak | |
| 17:31:53 | melwitt | oh good, it can fix everything automatically then | |
| 17:32:10 | mnaser | where a live migration python call in python-novaclient assumes nothing and sends rest, openstacksdk tries to workaround all the weird things we have and deliver a reasonable end result "a successful live migration" | |
| 17:32:14 | mnaser | https://review.openstack.org/#/c/589012/ | |
| 17:32:16 | mnaser | this is good though | |
| 17:33:05 | melwitt | oh, nice patch | |
| 17:33:27 | mnaser | it was in the etherpad, so it gets through that step at least | |
| 17:33:54 | melwitt | ah, I'm blind | |
| 17:35:01 | cfriesen | the thing I don't really like about openstackclient is that the help text isn't sensitive to API version | |
| 17:35:20 | artom | Very few things are :/ | |
| 17:35:48 | mnaser | im trying to force myself to use it | |
| 17:35:55 | mnaser | so that people can use it | |
| 17:37:26 | mnaser | btw | |
| 17:37:33 | mnaser | shall we update the topic? | |
| 17:38:05 | melwitt | we should but dansmith is out until next week. I'm not sure who else can do it | |
| 17:38:51 | mnaser | i can | |
| 17:39:52 | mnaser | let me know if you want to switch it to something else or whatever :> | |
| 17:45:11 | melwitt | oh, heh. ok, IIRC we had the current release schedule in it https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule and included the current runways, which would be use-nested-allocation-candidates right now | |
| 18:00:08 | mnaser | melwitt: wanna give me something to copy pasta into the topic? | |
| 18:00:29 | melwitt | yeah, lemme see. I can't remember what order it was in | |
| 18:01:46 | mriedem | i've talked with dtroyer about the osc live migration support, i think he basically wants to just re-write the command on a major version | |
| 18:02:04 | mriedem | mnaser: if you do specify a host with osc's live migration command, make sure you are using the microversion that doesn't bypass the scheduler | |
| 18:02:35 | mriedem | https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id27 | |
| 18:02:45 | mnaser | mriedem: i switched to using python-novaclient because i explicitly want the scheduler to decide for me | |
| 18:03:02 | mriedem | tbc, the live migration API explicitly requires that the host param is sent, it's not optional, but the value in the REST API can be None (it's dumb) | |
| 18:03:17 | mriedem | but ^ isn't possible in osc b/c you can't specify None on the command line | |
| 18:03:34 | mriedem | you would need to make --host optional | |
| 18:04:05 | mriedem | er --live <hostname> | |
| 18:04:06 | mriedem | https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-migrate | |
| 18:04:12 | mriedem | like, --live '' | |
| 18:04:18 | mnaser | mriedem: hence https://review.openstack.org/#/c/589012/ | |
| 18:04:28 | mriedem | yes, there is another one as well | |
| 18:04:42 | mnaser | but yeah i dunno | |
| 18:04:49 | mnaser | microversions for osc api? | |
| 18:04:53 | mnaser | heck yeah | |
| 18:05:10 | mriedem | https://review.openstack.org/#/c/460059/ | |
| 18:05:15 | mnaser | (i'm kidding please don't end me) | |
| 18:05:18 | mriedem | you can pass microversions through for osc | |
| 18:05:34 | mriedem | openstack --os-compute-api-version 2.30 migrate --live | |
| 18:05:39 | mriedem | or set an env var | |
| 18:05:48 | mnaser | yeah no but i meant like | |
| 18:05:51 | mriedem | osc doesn't do version negotiation to default to the latest like nova cli | |
| 18:05:54 | mnaser | the actaul openstack client shell api or whatever | |
| 18:06:13 | mnaser | but i guess we call those just *releases* of the client | |
| 18:06:48 | mriedem | https://review.openstack.org/#/c/460059/7//COMMIT_MSG@15 | |
| 18:06:51 | mriedem | has my suggestion in it | |
| 18:08:07 | mriedem | you also can't bfv with osc | |
| 18:08:13 | mriedem | unless you use an existing volume | |
| 18:08:22 | mriedem | those are two pretty big gaps in functionality | |
| 18:08:33 | mnaser | now on another note i think live migrations are scheduled when they are received, not when they start, right? | |
| 18:08:41 | mriedem | correct, | |
| 18:08:44 | mriedem | we have to pick the dest host | |
| 18:09:03 | mriedem | so we can setup things like port bindings and volume attachments | |
| 18:09:05 | mnaser | makes our hypervisor evacuations a bit more annoying in that we can kinda do one at a time | |
| 18:09:27 | mriedem | can only do? | |
| 18:09:54 | mnaser | well if we do host-evacuate-live on 3 nodes at once | |
| 18:09:58 | mnaser | its possible that they schedule to each other | |
| 18:10:14 | mnaser | (sometimes we actually do host-evacuate-live only for the purpose of having instances go in the right place after we make scheduler changes) | |
| 18:10:22 | mriedem | if you are evacuating the hosts, you could disable the compute service | |
| 18:10:33 | mriedem | not evacuate like the evacuate API, i mean "get the vms off this host" | |
| 18:10:48 | mnaser | yeah when we're shutting things down that's what we go for, but when shuffling things around | |
| 18:11:29 | mnaser | you kinda just want instances to move into where they are supposed to go | |