Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-01
19:58:02 efried mriedem: So like if I wanted to "clear the cache" I could add
19:58:33 efried or if I wanted to be narrower about it, I could add a reset() to the report client and invoke self.reportclient.reset() from there instead.
19:59:01 mriedem i reckon
19:59:03 sean-k-mooney efried: reset might be better
19:59:48 mriedem this just seems like a 180 in attitude about how important it is to having nova-compute be totally self-healing on every periodic
19:59:54 mriedem which i'm sure was debated to death in releases past
20:00:57 sean-k-mooney mriedem: well nothing is stopping us also reviving the notificaiton also to move the healing to a push model
20:01:42 mriedem there are plenty of things stopping me from doing anything
20:01:53 openstackgerrit Matt Riedemann proposed openstack/nova master: Clean up cpu_shared_set config docs https://review.openstack.org/614864
20:02:41 efried mriedem: I think a lot of the reasoning in the past was because information was coming from several different places while we were transitioning to placement but not fully there yet.
20:02:55 efried We're getting pretty close to fully there at this point, so I think a lot of this stuff is going to get to be cleaned up.
20:03:04 efried Like _normalize_allocation_and_reserved_bullshit()
20:04:11 mriedem efried: maybe, but i specifically remember you bringing up something once about how powervm shared storage pools can have disk swapped in and out on a whim and nova-compute should be cool with reporting that as it changes - but maybe that's unrelated to this, idk
20:04:59 efried mriedem: 1) that's not implemented yet, but 2) even when it is, that gels just fine with this, precisely because it's being node by virt.powervm.update_provider_tree and *not* out of band.
20:05:25 efried s/node/done/
20:05:41 mriedem ok i thought it was to handle some out of band thing
20:06:04 mriedem but it was awhile ago and i've been high on ether since then
20:06:35 sean-k-mooney well in additon to the sig hup stuff + disableing the cache refush via config =0 if we inject a sleep(random(refersh interval)) seconds to the specific periodic task once the jitter should sperad out the update over the entire interval smoothly on average
20:07:36 sean-k-mooney so for those that dont turn this off the same amount of update to placement will happen jsut not all at once every x seconds
20:10:25 mriedem i imagine cern would appreciate a way to disable the refresh altogether since they are already doing that out of tree
20:11:37 efried I'm working something up now.
20:11:57 sean-k-mooney efried: code or ml post or spec
20:13:05 efried sean-k-mooney: code
20:13:19 efried If it gets traction, I can spec it.
20:13:56 sean-k-mooney cool
20:15:03 sean-k-mooney mriedem: by the way i know your busy with other stuff but do you plan to revive https://review.openstack.org/#/c/538498/ at somepoint
20:16:48 mriedem it's pretty low priority
20:18:18 sean-k-mooney mriedem: ok i stared it. so in the unlikely event i run out of things to do i might take a look at it if you dont get back to it. but ya ther are many things ahead of it
20:27:36 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: High Precision Event Timer (HPET) on x86 guests https://review.openstack.org/607989
20:29:04 mriedem cfriesen: jackding: ^ i cleaned that up, +2
20:30:01 cfriesen mriedem: sweet, thanks. any chance you could take another look at the vtpm one?
20:30:09 cfriesen sean-k-mooney: you too
20:30:29 sean-k-mooney cfriesen: am sure
20:30:47 sean-k-mooney cfriesen: im respining a patch but ill take a look after
20:30:49 mriedem ffs yes you know i'd love t
20:30:50 mriedem *to
20:30:58 cfriesen you're so sweet
20:32:16 mriedem i have my moments
20:32:21 mriedem once per quarter
20:32:27 KeithMnemonic mriedem: can someone help move this along https://review.openstack.org/#/c/611326/1 ?
20:32:59 mriedem KeithMnemonic: umm, melwitt and/or dansmith could probably hammer that through
20:34:46 mriedem KeithMnemonic: how far back do you need that fix?
20:34:47 KeithMnemonic thanks melwitt: dansmith: can you help here ?
20:34:56 KeithMnemonic just pike
20:35:04 mriedem ok i can work on the queens and pike backports in the meantime
20:35:09 KeithMnemonic but it needs to get in rocky first then
20:35:13 mriedem yup
20:35:41 melwitt looking
20:35:49 KeithMnemonic thanks for helping out!!
21:02:16 openstackgerrit sean mooney proposed openstack/os-vif master: add support for generic tap device plug https://review.openstack.org/602384
21:02:17 openstackgerrit sean mooney proposed openstack/os-vif master: add isolate_vif config option https://review.openstack.org/612534
21:07:07 openstackgerrit sean mooney proposed openstack/os-vif master: always create ovs port during plug https://review.openstack.org/602384
21:07:08 openstackgerrit sean mooney proposed openstack/os-vif master: add isolate_vif config option https://review.openstack.org/612534
21:08:39 sean-k-mooney jaypipes: sorry for the delay i shoudl have adressed all your comments in ^ i have also reworded the commit message for the first patch to clarify things a little
21:10:20 mriedem cfriesen: done https://review.openstack.org/#/c/571111/
21:11:00 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Fix NoneType error in _notify_volume_usage_detach https://review.openstack.org/614868
21:11:30 cfriesen thanks. do you think we should deal with shelve/unshelve as part of this, given that it's broken for UEFI nvram currently?
21:12:10 mriedem i think if you're not going to deal with it now, it should be explicitly called out as a limitation
21:12:29 cfriesen okay, happy to do that
21:12:44 mriedem happier than adding shelve support anyway :)
21:13:08 cfriesen I think for both cases we'd need to store those files somewhere, either in glance or maybe swift (if present)
21:14:11 mriedem nova doesn't do anything with swift directly so idk
21:14:29 mriedem if only we had switched to glare 3 years ago when they wanted us to
21:15:35 cfriesen fyi, there are actual differences between 1.2 and 2.0 other than CRB
21:16:24 mriedem i figured maybe there were, but idk what they are
21:16:33 mriedem but assume people that care about using this would know the difference
21:16:45 cfriesen me too. :)
21:16:51 mriedem ooo https://www.dell.com/support/article/us/en/04/sln312590/tpm-12-vs-20-features
21:17:25 cfriesen my impression is that this stuff is all crazy complicated
21:17:35 sean-k-mooney cfriesen: yes yes it is
21:17:42 mriedem cool, let's add it to nova!
21:17:50 mriedem WHAT COULD GO WRONG?!
21:18:33 sean-k-mooney mriedem: well a version number is a lot better then traits for all the crap added in each versions
21:18:47 cfriesen you're giving me nightmares
21:19:00 mriedem i'm fine with reporting the different versions as traits
21:19:12 mriedem https://en.wikipedia.org/wiki/Trusted_Platform_Module#TPM_1.2_vs_TPM_2.0 could be a reference in the spec if we cared
21:19:19 mriedem sounds like 2.0 is more secure
21:19:34 sean-k-mooney cfriesen: the cloud plathform group gave me them frist when the wanted me to enable tpm traits 12 months ago
21:20:12 sean-k-mooney mriedem: yes it is
21:21:45 sean-k-mooney mriedem: when i was orignally try to standardise tpm trais i have multiple version traits https://review.openstack.org/#/c/514712/3/os_traits/hw/platform/security.py
21:22:02 sean-k-mooney but honelst 1.2 and 2.0 are all that matter
21:22:38 sean-k-mooney as far a i know very few deplopyment of tpm 1.0 or 1.1 were ever a thing
21:24:41 cfriesen on a totally different topic, I'd like to draw your attention to https://review.openstack.org/#/c/473973/
21:26:29 cfriesen originally we used these for the nova/neutron update where we were being blasted with a bunch of neutron updates. now with the changes to get fewer neutron updates it's probably not as big a deal, but we might want to consider using the fair locks in a few places.
21:27:38 sean-k-mooney cfriesen: so these are basically the opisite of pirority locks hehe
21:27:53 cfriesen they're like ticket spinlocks
21:29:09 sean-k-mooney cfriesen: just looking at the implementaiton
21:29:11 cfriesen the original problem we hit was that the nova-compute thread handling "real work" (like a migration or something) was being starved by tons of incoming neutron events that always got the lock first
21:29:55 cfriesen sean-k-mooney: for simplicity it uses the fact that fasteners writer locks are queued
21:30:13 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix NoneType error in _notify_volume_usage_detach https://review.openstack.org/614872
21:31:09 sean-k-mooney cfriesen: how does this interact with and without eventlets monkypatching
21:33:48 cfriesen should just work. the underlying stuff is threading.Condition
21:38:41 sean-k-mooney cfriesen: once comment if you re spin the patch but ya it neat
21:39:12 sean-k-mooney that said if you did not need a named lock you could jsut use the readerwriter lock directly
21:45:47 jackding mriedem: I forgot to push my change, Thank you for doing that.
22:06:06 sean-k-mooney cfriesen: so for real time guests do you care that we cant disable the perfomance moniting unit in the libvir xml in nova
22:10:08 cfriesen sean-k-mooney: I don't think it's come up. Do they default to on?
22:10:17 sean-k-mooney cfriesen: yep
22:10:41 sean-k-mooney i have no idea what the impact of that is
22:10:45 sean-k-mooney i assume low

Earlier   Later