Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-26
15:22:10 mordred kashyap: to be fair - a 9000-pound blue whale would actually be pretty awesome
15:22:35 kashyap aspiers: I didn't go to any other Denver event. This is the first time for me. (I make it to at most one OpenSt^H^H^OpenInfra event a year)
15:22:49 aspiers kashyap: ah ok
15:23:25 openstackgerrit Adam Spiers proposed openstack/nova master: Add new "supports_amd_sev" capability to libvirt driver https://review.opendev.org/638680
15:25:28 kashyap mdbooth: Heh. (I'm actually liking my "pivot" to "buy as much locally as you can, even if it's a tad more expensive". Although, I'm in a very convenient "city town" of 250K people, where I can get most things done via biking. I know that my fellow folks in the US (given its huge surface area) don't have the same convenience
15:26:01 efried stephenfin: What's your schedule for the PTG? Are you around all three days? Which bits are consumed with non-nova?
15:28:51 kashyap efried: For mine, you asked the other day -- if it's still possible, still got a slot on Saturday morning to move the Secure Boot? Sorry for the re-shuffle
15:29:10 kashyap (I won't cry into my pillow if you can't move it.)
15:29:10 efried looking
15:29:38 efried kashyap: 1045 Saturday morning?
15:29:45 kashyap Sure
15:29:48 kashyap Thank you!
15:30:06 efried kashyap: 15 minutes?
15:31:42 gibi_off mriedem: problem reproduced with the lastest patch set but the stack trace is still too long http://logs.openstack.org/68/654468/7/check/openstack-tox-py36/1c4087e/job-output.txt.gz#_2019-04-26_15_22_42_143486
15:32:41 kashyap efried: Yeah, should suffice.
15:32:46 efried k
15:32:49 kashyap I normally don't digress :D
15:32:52 mdbooth efried: I believe stephenfin is travelling today.
15:32:56 kashyap (If I may say so myself.)
15:32:57 efried kashyap: It's hardly you I'm worried about
15:33:10 efried mdbooth: ack, thanks.
15:35:52 kashyap efried: Guess you're sharpening your "no-ratholing" knife :D
15:36:09 efried kashyap: I'm bringing special choke holds
15:36:16 kashyap Haha
15:36:22 kashyap Sounds ominous.
15:37:00 kashyap "Shime-waza", I see.
15:38:19 mriedem gibi_off: hmm, wth
15:38:53 efried kashyap: ah, judo. The fact that they can enumerate their chokes...
15:38:54 mriedem i'm unable to set the recursion depth limit below 55, so bumped it to 100
15:39:25 mriedem but i wonder why the _get_counter in oslo.config isn't raising an error, unless the cache is getting reset along with our counter and that's why we continue to recurse
15:40:45 gibi_off mriedem: based on the stack trace it is now recursing on the code we added for trobleshooting https://review.opendev.org/#/c/654466/6/oslo_config/cfg.py@2627
15:40:46 mriedem methinks the cache is always getting reset
15:41:31 mriedem ha
15:41:32 mriedem sob
15:42:58 gibi_off accessing self._get_counter calls __getattr__ that calls back to _get
15:43:10 mriedem yup
15:43:16 gibi_off sh*t
15:43:57 mriedem so __getattr__ just needs to check for '_get_counter' and return it directly
15:43:59 mriedem rather than recurse
15:44:00 mriedem yeah?
15:44:05 gibi_off mriedem: yeah
15:44:17 mriedem updating
15:44:28 gibi_off mriedem: but then I don't get why the self.__cache cause the same thing
15:44:53 mriedem doesn't cause the same thing?
15:44:59 mriedem maybe it is...
15:45:04 mriedem and maybe that's the bug
15:45:09 gibi_off mriedem: doesn't call __getattr__
15:45:12 gibi_off ahh
15:45:30 gibi_off maybe that is the bgu
15:45:32 gibi_off as you said
15:46:59 mriedem o/
15:47:03 gibi_off o/
15:47:40 mriedem hmm, __getattr__ shouldn't even be called on an attribute that's already on self
15:47:40 mriedem https://docs.python.org/3.6/reference/datamodel.html#object.__getattr__
16:45:18 openstackgerrit Matt Riedemann proposed openstack/nova master: Add heal_instance_mappings command https://review.opendev.org/655908
16:45:19 mriedem mnaser: now with a buttload of tests and docs and a reno ^
16:55:35 openstackgerrit Eric Fried proposed openstack/nova-specs master: Abandon flavor-classes backlog spec https://review.opendev.org/649095
16:56:00 openstackgerrit Eric Fried proposed openstack/nova-specs master: Abandon instance-tasks backlog spec https://review.opendev.org/649100
16:56:08 openstackgerrit Eric Fried proposed openstack/nova-specs master: Abandon parallel-scheduler backlog spec https://review.opendev.org/649101
16:56:21 openstackgerrit Eric Fried proposed openstack/nova-specs master: Abandon same-instances-scheduling backlog spec https://review.opendev.org/649102
17:02:57 openstackgerrit Eric Fried proposed openstack/nova master: Remove [ironic]api_endpoint option https://review.opendev.org/643483
17:03:21 efried eandersson: rebased that on your fix ^
17:03:21 efried mriedem: since this is fresh in your head, would you please? ^
17:06:33 mnaser mriedem: awesome, thank you for picking that up.
17:09:40 efried mriedem: I have an idea for the cinder ksa opts.
17:10:51 efried The important thing - especially if we plan to ditch cinderclient - is that operators be able to use consistent opts. It matters less that we actually construct a ksa adapter (we just throw it away anyway).
17:11:33 efried So I propose to skip the common get_ksa_adapter util and instead explicitly use the ksa opts when available in place of the legacy cinder ones to do the same thing the legacy cinder ones do.
17:12:02 efried Should be a totally seamless transition for now. And then we have ksa opt support.
17:17:20 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Use ksa adapter for cinder client https://review.opendev.org/508345
17:17:52 efried (not this ^)
17:34:12 mriedem +2 on https://review.opendev.org/643483
17:34:19 mriedem idk about all that other sassafrass
17:56:45 mriedem final releases for pike are out
18:00:33 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Support ksa config opts for cinder https://review.opendev.org/655985
18:01:19 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Support ksa config opts for cinder https://review.opendev.org/655985
18:01:42 efried mriedem: it look like ^
18:05:28 mriedem artom: has there been any progress on the numa live migration series since stein?
18:05:47 artom mriedem, no :( New downstream fires keep popping up
18:06:31 mriedem not enough asbestos
18:08:13 artom mriedem, need to relocate RH head office here: https://goo.gl/maps/barnrHHvjL3B1kr57
18:11:15 mriedem you could work in that quarry
18:11:21 mriedem plenty of natural sunlight
18:11:23 mriedem fresh air
18:11:37 artom "fresh"
18:57:02 openstackgerrit Merged openstack/nova master: SR-IOV Live migration indirect port support https://review.opendev.org/620115
18:57:11 openstackgerrit Merged openstack/nova master: Fix mock specs set to strings https://review.opendev.org/655455
19:03:40 jaypipes aspiers, efried, kashyap: hmm, so if these things like ssbd, virt-ssbd, idpb, etc are actually *not* x86 CPU instruction set extensions, then perhaps we should carve out a completely different are in os-traits for them.
19:03:55 jaypipes aspiers, efried, kashyap: so, what exactly ARE these things then? :)
19:04:14 aspiers are they cpu flags detected by the kernel?
19:04:21 aspiers I have no idea, not looked at them
19:04:25 jaypipes I don't know :) I'm asking you guys...
19:04:49 efried kashyap is the best one to answer that, but I think aspiers got it right.
19:04:59 aspiers IIRC the kernel does expose cpu flags for certain things it spots in a chipset
19:05:22 aspiers vulnerabilities are the obvious example here
19:05:31 jaypipes or perhaps the actual answer is "they are some random bitmask for some ioctl() call that is entirely unstructured and hidden in some C header file in the kernel somewhere"
19:05:32 efried The docs describe them as "CPU features"
19:06:06 efried talk about turning them on and off
19:06:08 efried https://qemu.weilnetz.de/doc/qemu-doc.html#important_005fcpu_005ffeatures_005fintel_005fx86
19:06:19 efried (sometimes)
19:06:29 aspiers oh, there's a separate "bugs" line in /proc/cpuinfo

Earlier   Later