Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-16
15:35:46 openstackgerrit Lee Yarwood proposed openstack/nova master: virt: Provide block_device_info during rescue https://review.opendev.org/700811
15:35:46 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue https://review.opendev.org/700812
15:35:47 openstackgerrit Lee Yarwood proposed openstack/nova master: docs: Add stable device rescue docs https://review.opendev.org/700837
15:35:47 kashyap stephenfin: Yeah, I don't have a solid answer to that yet :-(
15:35:50 sean-k-mooney https://review.opendev.org/#/c/698846/ should be rebased on https://review.opendev.org/#/c/700261/
15:36:14 kashyap stephenfin: Let me see the original kernel report I quoted in the commit, maybe there's something in there
15:36:39 sean-k-mooney stephenfin: i have never seen hardware that actully does not have a dma regoin per numa node
15:37:10 openstackgerrit Lee Yarwood proposed openstack/nova master: DNM test stable rescue tempest/devstack changes https://review.opendev.org/700815
15:37:18 sean-k-mooney stephenfin: and i mean ever in the 7+ years i have been working on this stuff
15:37:50 sean-k-mooney so i am not surprised people have not hit this before
15:38:10 stephenfin efried: I think I'm going to have to get you to weigh in on https://review.opendev.org/#/c/696745/, because I _think_ I've addressed the concerns but everyone else is still avoiding it :)
15:38:38 kashyap sean-k-mooney: Ah, interesting
15:38:59 stephenfin It's almost all refactor noise _except_ the rename of 'nova.network.neutronv2.api' to just 'nova.network.neutron', and the subsequent removal of the 'nova.network.api' shim
15:39:35 kashyap sean-k-mooney: I don't have the data about the hardware assmuption here (which hosts might not have the DMA32 region): https://lkml.org/lkml/2018/7/24/152
15:40:26 sean-k-mooney kashyap: i also suspect that htis was not alway the behavior or kvm by the way
15:41:15 sean-k-mooney i proably had been that way for a long time but i susspect it was altered at somepoint
15:41:20 kashyap sean-k-mooney: FWIW, a bit ago I checked w/ Paolo (one of the upstream KVM devs); he confirmed it's "latent"
15:41:23 kashyap Probably
15:42:49 sean-k-mooney maybe i dont knwo why but if feel like if you grabed ubuntu 12.04 or centos 5.4 it likely wont happen
15:42:55 belmoreira stephenfin our batch VMs (running in dedicated compute nodes with NUMA/huge pages aware) are long lived VM
15:43:32 sean-k-mooney kashyap: i just get the feelign like there was a refactor of this at some point but i dont recall why i have that feeling
15:43:36 belmoreira true that we are seeing this issue for awhile. Until now our solution has been to reboot the affected node.
16:00:12 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: Avoid spurious error logging in _get_compute_nodes_in_db https://review.opendev.org/702902
16:06:12 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: Error out interrupted builds https://review.opendev.org/687918
16:06:26 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: Fix false ERROR message at compute restart https://review.opendev.org/699496
16:10:14 dansmith efried: do you have any opinions on the newer literal set syntax (i.e {1, 2}) ?
16:10:30 dansmith IMHO, it's one of the worst things ever, because it's super confusing and looks like a dict
16:10:59 dansmith just wondering if anyone else would be interested in a developer convention in nova of not adding code with that syntax to our tree
16:11:48 gibi dansmith: I have no problem with the literal set sytnax for me the absense of ':' is enough to notice that it is a set
16:12:06 dansmith it's super easy to not notice that there's no : though
16:12:17 gibi I guess we are different
16:12:20 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: Ensure source service is up before resizing/migrating https://review.opendev.org/701757
16:12:40 dansmith gibi: that's fine, I asked because I was wondering if I'm the only one
16:18:53 artom dansmith, as per your request, I'm not letting you forget https://review.opendev.org/#/c/687404/8
16:20:30 gibi dansmith: I think for me it is mostly about the fact that I used to it. I guess I would be pretty against assignment expression because that would be something I never used before in python
16:21:09 dansmith artom: okay I'm in the middle of one of the cyborg patches, which is making me angry because apparently validating that our new methods are called like we expect them to is far too high a bar
16:21:39 artom dansmith, to adjust nagging frequency, press 1 now ;)
16:22:11 dansmith gibi: I think it's confusing that foo={} is a dict but foo={1} is a set, and easy to confuse foo={1:2} with foo={1,2}, and set comprehensions look a lot like dict comprehensions
16:22:24 dansmith gibi: obviously you *can* tell the difference, it's just very easy to miss, IMHO
16:25:36 gibi I accept your view
16:25:41 dansmith hah
16:26:03 efried dansmith: I personally have no problem with {1, 2} set syntax. A set is a dict with only keys. And I don't have trouble distinguishing between commas and colons.
16:26:17 dansmith aight, well, that settles it then
16:26:26 artom " A set is a dict with only keys" Umm...
16:26:29 efried dansmith: but jaypipes expressed a distaste for it (for the same reasons) so I avoided it... until he was gone.
16:26:46 dansmith oh did he? damn, should have gotten my rule landed then
16:28:29 efried a) I think set((1, 2)) is overly verbose and unnecessary, b) my IDE warns that I should use a set literal, c) I believe set((1, 2)) is also less efficient because it first creates a tuple, then calls a method to turn it into a set.
16:29:34 efried obv b) I could ignore / turn off, and I'm sure c) is negligible in 99.99% of cases. But given aforementioned not-problem with the literal syntax, it's enough for me.
16:29:34 dansmith yeah, I don't like how verbose set() has to be, and yes there's some overhead but I think it's trivial in this case
16:30:05 dansmith ack
16:36:57 efried stephenfin: before I dig into that: I'm of the opinion that a) we should make it look like the other service API shims. nova/$service_type/$project_name.py; b) I don't see a need for a generic abstract API layer.
16:36:57 efried Is that what you've done?
16:41:17 sean-k-mooney dansmith: for what its worth i dislike {} as that allways meen a dict so i dont like useing it to initalise a default. i alway use set() if i want a set in that case
16:41:36 sean-k-mooney well if its empty that is
16:41:57 dansmith well, confirmation that I'm not crazy, at least
16:42:00 efried If set(1, 2) were allowed I would be less grouchy about it.
16:42:09 dansmith or.. "at least as crazy as sean-k-mooney" I guess :P
16:42:38 sean-k-mooney efried you have to do set({...}) right
16:42:41 efried but having multiple meanings for the same operator/punctuation doesn't bother me as long as it's clear from the context, which IMO it is in this case, because colons.
16:42:42 sean-k-mooney that is annoying
16:42:54 efried sean-k-mooney: set($iterable)
16:43:03 sean-k-mooney ya
16:43:16 efried so {...} if that's a set or a dict would work to get you a set of the keys; (...) for a tuple, [...] for a list etc.
16:43:16 dansmith stephenfin: same
16:43:31 sean-k-mooney stephenfin: becasue paython is annoying enough to parse as it is
16:43:51 efried I don't really get why that would be better; but I'm going to guess they chose {} because, as I said, a set is a dict without values.
16:43:59 sean-k-mooney <> i think is technically not equal in python 2
16:44:07 dansmith a set is not a dict with no values :)
16:44:16 stephenfin sean-k-mooney: indeed, it is
16:44:29 stephenfin I've seen that once in my life, I think
16:44:31 stephenfin (docutils)
16:44:41 efried dansmith: totally is. O(1) hashing, just no pointers out of the buckets.
16:44:51 dansmith sean-k-mooney: as hateful as they are, I can imagine them doing that in py3 to break compatibility for fun and profit.. I guess dict literals just got added too early :)
16:44:52 sean-k-mooney although i think its also the same as != and is checking identiy not equality but i might be wrong on that
16:45:07 dansmith efried: totally is not :)
16:45:38 dansmith it may be the same implementation under the covers, but that does not make the statement true :)
16:47:58 efried nova-live-migration seems to be ill. Anyone available to dig in?
16:53:40 dansmith I would think artom would be a good person to maybe start taking on some responsibility for that stuff given his numa LM work
16:54:05 dansmith building some context for the future and what not
16:54:54 sean-k-mooney i got landed with some downstream stuff but in theory i am ment to be helping porting those jobs to be non legacy too
16:55:27 sean-k-mooney efried: is it blocking ci or just starting to fail more then we would like
16:55:56 efried sean-k-mooney: It has tanked many patches in CI in the last 18h or so.
16:56:05 efried doesn't seem to be 100%, but it's close.
16:56:17 efried I haven't looked into it at all because I haven't yet been bothered to f'ing unzip the logs.
16:56:35 sean-k-mooney has my patch merged to fix that yet
16:56:46 sean-k-mooney you rechecked it this morning/last night right
16:57:04 efried your patch did merge, yes. Not sure if any of the failed jobs started since then.
16:57:05 sean-k-mooney ya looks like it di
16:57:52 efried I don't even know if the failures are the same across the board. I just know many have been failing. (Most of the nova-next failures are due to 'multiple possible networks', which I'm fixing elsewhere.)
16:58:24 sean-k-mooney yes with your tempest patch
17:00:14 sean-k-mooney that should also be merged now. if no one else fixes it ill try and get though these backprots then i can look at ci but proably tomorow or monday.
17:08:07 efried stephenfin: +2 on https://review.opendev.org/#/c/696745/
17:08:07 efried I guess controversy was in previous versions.
17:08:07 efried I get the gripe about making backports difficult, but the code base will just get messier and messier if we don't bite the bullet and clean this stuff up from time to time.
17:08:07 efried Besides, I don't see backports being hugely affected by this.
17:08:07 efried So ++
17:08:23 stephenfin thanks
17:26:46 efried I can't even see why https://zuul.opendev.org/t/openstack/build/093f129de3ca47549239eed0d6acf288 is failing. The job output says devstack failed, but the devstack log looks okay to me. Anyone? Bueller?
17:29:48 efried /opt/stack/new/devstack/lib/databases/mysql: line 64: mysql: command not found
17:29:48 efried ^ on the subnode. wtf?

Earlier   Later