Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-12
15:55:40 bauzas but we stick with the plan you wrote
15:55:53 gibi bauzas: yeah, there was no way to fitt everything
15:55:54 bauzas FWIW, I wish I could have had time for this with VGPU support...
15:56:06 gibi bauzas: let's try that again in U
15:56:17 stephenfin melwitt: ta for https://review.opendev.org/681374 (y)
15:56:20 bauzas every cycle, I make myself a promise
15:56:29 bauzas I stopped doing it
15:57:36 luyao stephenfin: reminder for vpmems series. :)
15:57:51 stephenfin luyao: https://review.opendev.org/#/c/678452/32 :)
15:58:04 bauzas stephenfin: I'm balancing in my head the need for defaulting disable_fallback_pcpu_query to True as default
15:58:28 melwitt stephenfin: np, good call on keeping the quota tests with it and moving the other unrelated func test to the next patch
15:58:29 stephenfin bauzas: It's the same discussion we had with the previous manual configuration option
15:58:45 bauzas yeah I now
15:58:47 bauzas know*
15:59:02 stephenfin melwitt: Yeah, thank mriedem for that (he complained (fairly) that the next one was way too big)
15:59:33 luyao stephenfin: thanks, not noticed that.:)
15:59:49 openstackgerrit Balazs Gibizer proposed openstack/nova master: Follow up for Ib50b6b02208f5bd2972de8a6f8f685c19745514c https://review.opendev.org/681490
16:01:59 gibi bauzas, mriedem: could you re-apply your love there? ^^
16:02:19 bauzas gibi: a safe love but yeah
16:02:27 openstackgerrit Balazs Gibizer proposed openstack/nova master: Skip querying resource request in revert_resize if no qos port https://review.opendev.org/681513
16:02:48 gibi bauzas: :)
16:03:55 mriedem consider my love applied
16:04:12 gibi mriedem: thanks
16:04:52 artom Eww
16:05:08 mriedem hey,
16:05:17 mriedem nothing eww about a grown man loving up on some patches
16:06:34 bauzas stephenfin: https://review.opendev.org/#/c/671801/48/releasenotes/notes/cpu-resources-d4e6a0c12681fa87.yaml@35 worth considering a nova-status upgrade check that would verify before you upgrade to Ussuri that you no longer require the workaround
16:06:46 melwitt mnaser: fyi os-vif 1.15.2 has been released https://review.opendev.org/681358
16:07:19 bauzas anyway, dropping now, but I'll be back later (doing a bit of trail running)
16:07:29 stephenfin bauzas: Yup, good call. That's what we did for the consoleauth workaround
16:08:02 stephenfin dansmith: Can we squash migrations in the future?
16:08:20 dansmith stephenfin: what migrations?
16:08:38 stephenfin i.e. "INFO migrate.versioning.api [-] 254 -> 255..."
16:08:48 stephenfin our DB migrations
16:09:17 dansmith we've compacted them before, but not in a long time, as you know
16:09:20 dansmith so.. yes?
16:09:26 stephenfin I did not know that
16:09:30 stephenfin or rather, I'd forgotten it
16:12:21 mriedem stephenfin: my recollection with that is sdague heard from a bunch of operators at one point that they actually didn't like the compacting because it f'ed up things like FFUs
16:12:29 mriedem this was long before FFU was even a term
16:12:34 mriedem so "skip level upgrades" at the time
16:12:54 dansmith yeah it's a giant pain
16:12:55 mriedem so we stopped doing it,
16:12:57 mriedem and,
16:12:58 stephenfin understandable. That's why I was thinking Queens
16:13:01 melwitt mriedem: I'm +1 on the top patch of brinzhang's set and I see you are +1 on the middle patch. I'm wondering if I should fix up the bottom patch since I doubt brin is around the rest of today
16:13:03 stephenfin rather than Train or something more recent
16:13:13 mriedem the amount of new schema migrations we do compared to the old days is nowhere close
16:13:22 dansmith also true
16:13:33 dansmith we chewed through a ton early on, but it's rare today
16:13:54 stephenfin I bring it up because I'm deploying on a machine locally and they're taking forever
16:13:59 mriedem dan prince had a schema diff tool thing since he was the one that used to do it but i'm not sure if that works anymore
16:14:27 stephenfin but that machine is using a HDD so that could be a limiting factor
16:14:51 mriedem melwitt: i've got an appointment this afternoon and haven't been back on the api change itself yet, so i'm not sure i'm going to be able to get that done today,
16:15:00 mriedem melwitt: you could fix up the bottom change though yeah it's just simple testing
16:15:25 mriedem i also have a patch i've been meaning to update and get into placement this release that i need to spend some time on
16:16:13 melwitt mriedem: ack. I'll do it just in case but won't expect you'll be able to be back to it today
16:17:24 openstackgerrit sean mooney proposed openstack/nova master: [DNM] cpu pinning testing https://review.opendev.org/681807
16:19:17 sean-k-mooney ok i think ^ is correct
16:19:35 sean-k-mooney stephenfin: can you check https://review.opendev.org/#/c/681807/1/playbooks/nfv/pinning.yaml
16:19:41 stephenfin sure
16:19:58 sean-k-mooney those flavors are correct right?
16:20:53 sean-k-mooney i need to start makeing the other 2 version vcpu_pin_set only where i will have to drp the expcitly resouce request and cpu_dedicated_set only which shuld just work
16:21:01 sean-k-mooney e.g. no flavor changes needed
16:21:05 stephenfin sean-k-mooney: the first one has vcpus=1 but '--property hw:cpu_threads=2'
16:21:13 stephenfin that'll conflict, surely
16:21:21 sean-k-mooney actully ya it might
16:21:28 sean-k-mooney it previously had 2 vcpus
16:21:35 sean-k-mooney ill fix that
16:21:40 sean-k-mooney anything else
16:21:45 stephenfin Personally I'd just drop the CPU topology stuff since it's not relevant to this
16:21:46 stephenfin looking
16:22:09 sean-k-mooney i just did
16:22:10 stephenfin '--property hw:cpu_policy=dedicated --property resources:PCPU=2'
16:22:12 stephenfin that'll fail
16:22:22 sean-k-mooney that shoudl not
16:22:26 stephenfin you've to do one or the other. We enforce that at the API
16:22:34 sean-k-mooney oh ok
16:22:49 sean-k-mooney but wait no that does not make sense
16:23:02 sean-k-mooney if you just did --property resources:PCPU=2
16:23:07 sean-k-mooney then you would not get cpu pinning
16:23:21 sean-k-mooney so why would we ever allow that
16:23:22 stephenfin you will - PCPU == a pinned CPUs
16:23:33 sean-k-mooney we should not allow that
16:23:51 stephenfin 'hw:cpu_policy=dedicated' is syntactic sugar for 'resources:PCPU=$(flavor.vcpus)'
16:23:53 sean-k-mooney didnt we say we woudl only do pinning if you had dedicated
16:24:14 stephenfin A PCPU is a resource for dedicated CPUs
16:24:15 sean-k-mooney yes but we dont want to supprot people useing --property resources:PCPU=2 long term
16:24:21 dansmith sean-k-mooney: why?
16:24:26 dansmith that's exactly what I want
16:24:37 sean-k-mooney because you have to change your flavors if we change how we modle it in placement
16:24:50 dansmith I'm fine with that
16:24:57 sean-k-mooney also it will break if you enable multiple numa nodes in the image
16:25:19 stephenfin break how?
16:25:21 stephenfin or when?
16:25:46 sean-k-mooney when numa is modles in palcmeent. it will add the request to the un numbered group
16:26:13 sean-k-mooney but if you had hw_numa_nodes=2 in the image and resources:PCPU=2 in the falvor it would fial
16:26:25 sean-k-mooney you would have to use teh numbered resouce request synatx
16:26:31 sean-k-mooney in the flavor instead
16:27:01 stephenfin in a future where NUMA is in placement, yes, you would need to use a different syntax

Earlier   Later