Earlier  
Posted Nick Remark
#openstack-nova - 2018-11-08
20:21:30 mriedem efried: melwitt: ok i'm +2 on those two nova changes
20:22:21 melwitt thank ya
20:22:35 mriedem i'm not sure why https://review.openstack.org/#/c/616371/ is failing though
20:22:49 mriedem oh i see,
20:22:51 mriedem it needs https://review.openstack.org/#/c/615724/
20:22:58 mriedem but that depeneds on 616731
20:23:02 mriedem *371
20:23:07 mriedem so we just need to land the nova changes
20:23:18 mriedem well...
20:23:39 mriedem but the top nova change can't land w/o that requirements dependency, which is failing b/c the code is still mocking the removed thing
20:24:12 melwitt yeah :/
20:24:16 melwitt efried halp
20:24:54 efried melwitt: o/ Sorry, was getting a CT of my face. Took an elbow yesterday. (Don't worry, I'm sure it'll still be rainbow-colored next week for ya)
20:25:18 melwitt damn, sorry to hear that
20:25:23 melwitt hope you are ok
20:26:00 efried I'll know more in an hour. Hopefully no orbital/sinus fractures.
20:26:07 efried so, that bizarre requirements chain...
20:26:09 efried checking...
20:29:05 efried Three out of four are passing zuul, but https://review.openstack.org/#/c/616371/ isn't, and it's the cross-nova check that's being pooty...
20:29:56 efried melwitt, mriedem: Heading back to the requirements channel to pick this up...
20:46:15 mriedem dansmith: replied in https://review.openstack.org/#/c/569055/ for a case in which i think it makes sense to only ever count quota for cells in which the project has instances
20:46:58 openstackgerrit Merged openstack/nova master: Fix support matrix for VMware UEFI support https://review.openstack.org/615870
20:47:38 dansmith mriedem: yeah, that's what I was saying
20:48:01 dansmith mriedem: we could still ignore the failed cell 5 in your example and let the create continue, but we'd have sat around waiting for it for no reason
20:50:25 mriedem in order to ignore it though, we'd have to determine if the project has instances in that cell, right? which means doing the instance mapping by project_id lookup anyway
20:50:29 melwitt nova meeting in 10 min
20:50:34 dansmith mriedem: yep
20:50:42 mriedem so we might as well just always do that
20:50:48 dansmith mriedem: this is my point
20:51:16 melwitt yeah, I think I got confused by the other instance list check where we could save on pruning cells if there's only one cell
20:51:16 mriedem in the case of a cloud that's not multi-cell, do we care about optimizing this?
20:51:49 dansmith mriedem: yeah you could filter out cell0 from the cache and if the result is only one avoid the lookup
20:51:49 melwitt I had thought there was a config option for avoiding that for single cell. and confused it with the quota situation
20:52:08 mriedem instances in cell0 still count against your quota though
20:52:11 mriedem i'm pretty sure
20:52:13 melwitt yeah they do
20:52:19 melwitt error instances, for example
20:52:32 dansmith yeah, I know,
20:52:35 melwitt oh, but you're saying don't count cell0
20:52:36 melwitt yeah
20:52:53 dansmith so you could also just say len(cache)==2, but.. checking that there is only one non-cell0 cell seems like a better assertion
20:53:34 mriedem wfm
20:53:41 dansmith other things would be wrong if those weren't the same, for sure, it just seems more of a positive thing
20:53:42 dansmith but that's just a detail, either way that optimization is easy
20:53:55 melwitt yeah. we could have a "is_single_cell" method. though I wonder how that works before the cache has been populated. I guess we know it has been before quota checks happen?
20:54:21 dansmith if the cache isn't populated then we have to populate it before we look at the cache
20:54:25 dansmith that's how all that code works
20:54:37 melwitt ok
20:54:43 dansmith so is_single_cell() makes a _load_cells() call first
21:05:24 artom This is weird, why is conductor failing with 'CantStartEngineError: No sql_connection parameter is established'
21:06:34 mriedem artom: it's trying to hit the API DB
21:06:36 mriedem and not configured for it
21:06:39 mriedem if you're using devstack
21:06:45 mriedem the cell conductor that is
21:06:54 artom mriedem, that's exactly it, it's almost creey ;)
21:07:12 mriedem e.g. resize fails on compute1, casts back to cell conductor which looks up the instance mapping and kablamo
21:07:14 mriedem known issue
21:07:19 artom It's a reschedule, the (presumably cell) conductor is trying to get the AZ
21:07:33 mriedem yup, i know the bug
21:07:35 mriedem sec
21:08:02 mriedem artom: linked from https://blueprints.launchpad.net/nova/+spec/fix-reschedule-up-calls
21:08:14 mriedem i have a fix for one of those
21:08:17 mriedem discussed at the ptg
21:08:17 artom Thanks :)
21:08:25 openstackgerrit Jack Ding proposed openstack/nova master: Add cache=none option for qemu-img convert https://review.openstack.org/616692
21:08:31 mriedem the other, the one you're hitting, is a bigger change b/c we have to pass the azs down to the cell
21:08:32 artom Actually also affects plain boot
21:08:34 mriedem on the Selection object
21:09:06 artom Hah, so I kinda need this fixed so that I can reproduce *another* bug correctly
21:09:27 mriedem artom: b/c of this right? https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L678
21:09:42 artom mriedem, yep
21:09:44 mriedem artom: well as a workaround just configure the [api_database]/connection in your nova-cell1.conf
21:09:47 mriedem and restart the cell conductor
21:09:57 artom Ah, true
21:10:22 mriedem i think devstack is the only thing out there that really does this split MQ thing
21:10:37 mriedem everyone else just runs with api db configured everywhere
21:10:59 artom Doesn't that kind of defeat the scalability point of the API db?
21:11:11 mriedem it's not really a scalability thing,
21:11:15 mriedem it's an isolation thing
21:11:39 artom OK - I just thought, if you're going to have all conductors talk to the api db, then why have a separate API db in the first place?
21:11:49 mriedem https://docs.openstack.org/nova/latest/user/cellsv2-layout.html#operations-requiring-upcalls
21:11:51 mriedem b/c dude
21:12:23 artom (Not being flippant on purpose or anything, genuinely trying to grok this)
21:13:06 mriedem b/c some things are in the api db schema like aggregates and cells, and some things are cell-specific, and we don't need to replicate that api db information across all cells
21:14:15 artom Ah, I see.
21:14:32 mriedem like cells v1 did
21:14:35 mriedem it had to sync everything
21:14:48 artom The API DB wasn't born out of a need to reduce load, it was born out of a need to keep a single source of truth for things that are common across all cells
21:14:59 artom It's the *cells DBs* that are the scalability stuff
21:15:07 mriedem yeah
21:15:36 artom Got it. Thanks :)
21:39:43 openstackgerrit Doug Hellmann proposed openstack/nova master: Use SleepFixture instead of mocking _ThreadingEvent.wait https://review.openstack.org/615724
21:39:43 openstackgerrit Doug Hellmann proposed openstack/nova master: Cap oslo.service to 1.32.0 (temporarily) https://review.openstack.org/616591
21:39:44 openstackgerrit Doug Hellmann proposed openstack/nova master: remove mocks of oslo.service private members https://review.openstack.org/616697
21:51:02 openstackgerrit Doug Hellmann proposed openstack/nova master: Use SleepFixture instead of mocking _ThreadingEvent.wait https://review.openstack.org/615724
21:51:02 openstackgerrit Doug Hellmann proposed openstack/nova master: remove mocks of oslo.service private members https://review.openstack.org/616697
21:51:14 efried melwitt, mriedem: Y'all still around to approve the new version of the oslo.service mess?
21:52:59 melwitt efried: yeah
21:53:20 efried melwitt: First https://review.openstack.org/616697
21:53:20 melwitt the top change says merge conflict tho

Earlier   Later