Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-27
15:56:38 melwitt true. we didn't use ceph
15:57:28 mriedem mnaser: you're asking about having the RamWeigher applied to an aggregate?
15:57:37 bauzas mriedem: that's from Queens, right?
15:57:42 bauzas I remember the CVE
15:57:48 mriedem bauzas: i think so, but it was backported so ...
15:57:56 bauzas mriedem: okay
15:58:16 mriedem mnaser: reminds me of Kevin_Zheng's spec https://review.openstack.org/#/c/599308/
15:58:43 mriedem trying to make the weight configuration not global
16:00:30 mgagne mriedem: yes and I commented that I had a similar solution per aggregate, not per flavor. code posted above in a gist =)
16:03:15 mriedem mgagne: ok i remember reading your comment but totally missed the part about having the weight configuration per aggregate
16:03:50 mriedem so Kevin_Zheng's spec is maybe way too extreme on the granular side, being per-flavor,
16:04:02 mriedem but global weight configs is also pretty extreme,
16:04:12 mriedem it seems per-aggregate weight configuration would be a nice compromise
16:05:15 bauzas mriedem: mgagne: I think there was a consensus on that approach, even at the PTG
16:05:42 bauzas putting on a flavor, I nacked, but I'm okay with it per aggregate
16:05:59 bauzas (in the spec, I meant)
16:06:41 mriedem yeah i totally didn't connect the dots on what the alternative was (weights per aggregate)
16:06:54 mriedem i must have been thinking about just pinning flavors to aggregates or something, idk
16:07:03 bauzas you can mix both indeed
16:07:03 openstackgerrit Matthew Booth proposed openstack/nova master: Fix a race evacuating instances in an anti-affinity group https://review.openstack.org/605436
16:07:10 bauzas if that helps your case
16:07:33 bauzas stick flavors to aggregates, the latter having specific weight policies
16:07:47 bauzas that would fit Kevin_Zheng's concern
16:08:09 bauzas anyway, I need to disappear for a meetup, \o
16:14:01 nicolasbock mriedem: Hi. I had asked you about "lost" servers a while back, i.e. servers that were migrated but nova's database was not updated. You had mentioned that resource provider allocation show will tell me about where placement thinks the server is running.
16:14:19 cfriesen gmann: sorry, I didn't notice your question earlier. the validation of flavor extra-specs and image properties would be done on instance creation, instance resize, and instance rebuild.
16:14:42 nicolasbock Unfortunately, in our deployment none of the hypervisors shows anything using this command
16:15:19 nicolasbock Is there an issue with placement? Or are we missing some configuration? Sorry if I sound confused, but I am ;)
16:19:05 openstackgerrit Chen proposed openstack/nova master: remove commented-out code https://review.openstack.org/605635
16:21:21 melwitt nicolasbock: for that command, you need to pass the instance uuid "the consumer". did you pass that or something else? https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-allocation-show
16:22:34 nicolasbock melwitt: I ran 'resource provider list' first and took the UUIDs as argument for 'resource provider allocation show'
16:23:27 melwitt nicolasbock: ok, those would be the compute host uuids, which is not what you need to pass. you need to pass the uuid of the instance/server, that is "lost"
16:24:09 melwitt and then it will show you information about that instance's allocations and where they are, which resource provider aka which compute host
16:25:07 nicolasbock Oh sorry, I totally misunderstood the command :(
16:25:09 nicolasbock It's working much better now
16:25:41 nicolasbock Thanks!
16:25:44 melwitt no worries, I had thought the same thing the first time I learned about the command
16:43:39 cfriesen mdbooth: I think I found a flaw in your fail-fast algorithm for https://review.openstack.org/605436
16:46:42 cfriesen We're proposing kind of a "big hammer" fix for a missing marker during online data migration. (https://review.openstack.org/#/c/605164/) Does anyone have a more elegant solution?
16:56:45 mriedem melwitt: nicolasbock: https://docs.openstack.org/osc-placement/latest/cli/index.html#cmdoption-openstack-resource-provider-allocation-show-arg-uuid describes the uuid but we could rename that metavar to be consumer_uuid so it's more obvious from the beginning
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?

Earlier   Later