Earlier  
Posted Nick Remark
#openstack-nova - 2018-09-27
16:57:19 mriedem consumers aren't a top-level resource in placement so that's probably why it's confusing
16:57:26 mriedem unlike openstack resource provider show https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-show
16:57:41 melwitt yeah. it does say "consumer". I think the confusion comes from the fact that it's in the resource provider command family
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

Earlier   Later