| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-01 | |||
| 19:50:28 | sean-k-mooney | so there is not race | |
| 19:50:41 | mnaser | i still don't see the need for constantly updating, sounds like this is something that you can just report once on start up or when it changes | |
| 19:50:42 | sean-k-mooney | well unless the clinet is coded badly | |
| 19:50:49 | efried | mnaser: Yes | |
| 19:51:03 | mnaser | MAYBE pull it in when a new VM gets spun up | |
| 19:51:18 | mnaser | if it means a different codepath | |
| 19:51:51 | sean-k-mooney | so currntly resource_provider_association_refresh has a min vlaue of 1. can we allow 0 and define that to mean update cache only on startup or sig hup | |
| 19:53:44 | sean-k-mooney | mriedem: did you not have a propsal to report things like support_migration as traits too | |
| 19:53:48 | cfriesen | dunno what's going on today, I keep disconnecting | |
| 19:54:06 | sean-k-mooney | mriedem: or is that handeled by the compute manager above the virt dirver level | |
| 19:54:28 | mnaser | anyways thats my 2 cents | |
| 19:56:12 | efried | mriedem, sean-k-mooney: Is ComputeManager.reset() the right hook for that SIGHUP thing? | |
| 19:56:14 | mriedem | sean-k-mooney: https://review.openstack.org/#/c/538498/ | |
| 19:56:31 | mriedem | efried: yeah | |
| 19:56:48 | sean-k-mooney | mriedem: ah ya that is what i was thinking of | |
| 19:57:42 | openstackgerrit | Merged openstack/nova master: PowerVM upt parity for reshaper, DISK_GB reserved https://review.openstack.org/614643 | |
| 19:58:02 | efried | mriedem: So like if I wanted to "clear the cache" I could add | |
| 19:58:02 | efried | self.scheduler_client = scheduler_client.SchedulerClient() | |
| 19:58:02 | efried | self.reportclient = self.scheduler_client.reportclient | |
| 19:58:02 | efried | to that method | |
| 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 | |