| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-01 | |||
| 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 | |
| 22:11:12 | sean-k-mooney | but i have an internal email asking about turning realtime instance and that was the only itme that is not already supported upstream | |
| 22:11:51 | sean-k-mooney | i could write a patch to allow disableing it in like an hour just not sure its worth my time and or if people would accpet the patch if i did | |
| 22:12:40 | cfriesen | sean-k-mooney: I don't see a "perf" section if I do "virsh dumpxml" | |
| 22:13:05 | cfriesen | maybe we default it to off or something in libvirt | |
| 22:13:53 | sean-k-mooney | its in this section https://libvirt.org/formatdomain.html#elementsFeatures | |
| 22:14:06 | sean-k-mooney | and its defalted to on in libvirt | |
| 22:16:02 | cfriesen | "virsh domstats --perf <domain>" gives me nothing | |
| 22:16:56 | sean-k-mooney | cfriesen: virsh dumpxml | grep pmu ? | |
| 22:17:24 | cfriesen | nothing | |
| 22:17:43 | sean-k-mooney | what version of libvirt are you running | |
| 22:17:55 | sean-k-mooney | the docs could be wrong | |
| 22:18:00 | cfriesen | 3.5.0 | |
| 22:18:18 | sean-k-mooney | and qemu | |
| 22:18:44 | cfriesen | qemu-kvm-ev-2.10.0 | |
| 22:19:29 | sean-k-mooney | ok it said since 1.2.12 ill assume the docs are wrong until they show me a vm xml with this from an openstack instance | |
| 22:20:44 | cfriesen | I have a specific CPU model though, not host-passhtrough, if that matters | |
| 22:21:19 | sean-k-mooney | it may in this case it was using host-passtrogh | |
| 22:21:38 | sean-k-mooney | that said i pmu is not a cpu flag so it should not | |
| 22:23:49 | sean-k-mooney | actully maybe when the default is on it just does not include it in the xml | |