| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-03 | |||
| 22:03:23 | aspiers | OK that was very helpful, thanks a lot! | |
| 22:04:09 | efried | neat | |
| 22:04:10 | aspiers | BTW your "I don't know enough about libvirt to be helpful" stance just lost all credibility ;-) | |
| 22:04:27 | aspiers | not that I ever believed it anyway X-D | |
| 22:04:37 | efried | hah, read the transcript again. It should be even more clear that I know jack about libvirt. | |
| 22:04:40 | sean-k-mooney | efried: you can set the default machine_type in the nova.conf too | |
| 22:05:00 | aspiers | sean-k-mooney: that's what I just said ;-) | |
| 22:05:02 | sean-k-mooney | efried:so you dont have to set it in the image always | |
| 22:05:03 | efried | yeah, that ^ sounds like it would be a good option for deployers wishing to enable SEV on their hosts. | |
| 22:05:16 | efried | can you do the uefi thing in nova.conf too? | |
| 22:05:25 | sean-k-mooney | no | |
| 22:05:28 | efried | bummer | |
| 22:05:35 | sean-k-mooney | at least not that im aware of | |
| 22:05:41 | aspiers | that might be a nice feature to add | |
| 22:06:05 | sean-k-mooney | eventrually we do want to change the defualt machie type to Q35 by the way | |
| 22:06:08 | aspiers | that would actually be really easy | |
| 22:06:24 | aspiers | sean-k-mooney: yeah I mentioned that too | |
| 22:06:26 | sean-k-mooney | adding the bios/uefi | |
| 22:06:33 | sean-k-mooney | ya it should not be hard | |
| 22:06:54 | aspiers | sean-k-mooney: https://bugs.launchpad.net/nova/+bug/1780138 | |
| 22:06:55 | openstack | Launchpad bug 1780138 in OpenStack Compute (nova) "Don't assume the guest machine type to be of 'pc'" [Medium,Confirmed] - Assigned to Kashyap Chamarthy (kashyapc) | |
| 22:07:12 | sean-k-mooney | although you do need to have the firmware ectra but i can see people wanting to eventurally mvoe the Q35+uefi only | |
| 22:08:31 | sean-k-mooney | ya we shoudl avoid assumign pc but its also wrong to assume q35 currently | |
| 22:09:22 | sean-k-mooney | we have a function that returns the correct machine type taking into account the default + config + image | |
| 22:09:43 | sean-k-mooney | if we dont know what to use we should call that rather then guessing | |
| 22:10:48 | sean-k-mooney | aspiers: by the way https://review.opendev.org/#/c/666915/16/nova/tests/functional/libvirt/test_report_cpu_traits.py were the changes i need to make the sev code work with my series | |
| 22:11:37 | aspiers | sean-k-mooney: resetting the traits cache makes sense | |
| 22:11:46 | aspiers | sean-k-mooney: two questions about resetting domain caps cache | |
| 22:11:56 | aspiers | 1. how did my tests pass without that before? | |
| 22:12:01 | sean-k-mooney | technically i think you should have always been doing self.compute.driver._host._domain_caps = None in your orginal code | |
| 22:12:11 | sean-k-mooney | aspiers: i think it should not or it was a race | |
| 22:12:14 | aspiers | 2. why not do it on both tests? | |
| 22:12:44 | aspiers | AFAICS it can't be a race because we're only talking about a single thread here | |
| 22:12:53 | sean-k-mooney | the second test does not modify the capablities but it would be valid to do it for both | |
| 22:12:57 | openstackgerrit | Merged openstack/nova master: libvirt: Fold in argument to '_update_provider_tree_for_vgpu' https://review.opendev.org/676729 | |
| 22:13:25 | sean-k-mooney | aspiers: i ment between fucntional test and the order they execute in | |
| 22:13:34 | aspiers | oh ok the second test doesn't look up caps because it gives up as soon as it sees the kernel parameter file missing | |
| 22:13:42 | sean-k-mooney | yep | |
| 22:14:07 | aspiers | but the compute host isn't shared between the tests surely? | |
| 22:14:26 | sean-k-mooney | it depens on how your mocking. | |
| 22:14:39 | sean-k-mooney | it should not be but i have seen wierd issue | |
| 22:15:19 | aspiers | start_compute() is called by each test | |
| 22:15:37 | aspiers | and creates a fresh compute service | |
| 22:16:18 | sean-k-mooney | when i ran it under the debugger i found you were not geting to the updated domain caps because of https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L759-L760 | |
| 22:16:37 | aspiers | right | |
| 22:17:12 | aspiers | er | |
| 22:17:48 | sean-k-mooney | i dont really know why it passed before but self.compute.driver._host._domain_caps = None seams to fix it | |
| 22:18:09 | aspiers | actually I think it's https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1191 | |
| 22:18:23 | aspiers | if the kernel param file is missing, it won't cache any caps | |
| 22:18:45 | aspiers | so when it appears later, it will call the fake getDomCaps API for the first time | |
| 22:18:47 | sean-k-mooney | no i steped throug it in the debugger | |
| 22:18:53 | aspiers | that's in the off_on case | |
| 22:19:26 | sean-k-mooney | it might be becasue of my traits code actully | |
| 22:19:32 | aspiers | in the on_off case, it wouldn't even care what caps were cached when it gets to off | |
| 22:19:53 | aspiers | but technically I think it's good to reset both caches in both tests | |
| 22:20:09 | aspiers | in case the order of tests ever got changed in the future | |
| 22:20:23 | sean-k-mooney | im calling this https://review.opendev.org/#/c/666915/16/nova/virt/libvirt/driver.py@6832 | |
| 22:20:38 | aspiers | sorry, I mean the order of these https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1188-L1193 | |
| 22:21:06 | sean-k-mooney | sure ill add that | |
| 22:21:28 | sean-k-mooney | it make it symetic and really we dont want the order of those check to break this | |
| 22:21:40 | aspiers | right | |
| 22:21:51 | aspiers | that static_traits looks fine to me | |
| 22:22:00 | aspiers | except for the blank line after the def ;-) | |
| 22:22:13 | sean-k-mooney | anyway the change looks sane to you? | |
| 22:22:17 | aspiers | yes | |
| 22:22:30 | aspiers | I didn't review the whole thing yet, but that file does | |
| 22:22:52 | aspiers | oh, according to Gerrit I did review the whole thing | |
| 22:22:54 | aspiers | I forgot :) | |
| 22:22:55 | sean-k-mooney | there is no other change to that form the previous versin | |
| 22:22:58 | sean-k-mooney | yes | |
| 22:23:05 | sean-k-mooney | a week or so ago | |
| 22:23:08 | aspiers | k | |
| 22:23:26 | sean-k-mooney | it been wait since and the only change was resolving the merge conflcit with the sev code | |
| 22:23:34 | aspiers | not since PS9 | |
| 22:23:58 | aspiers | I hate how this old Gerrit makes it so hard to compare patchsets after rebase | |
| 22:24:11 | aspiers | that's the #1 thing I want a new Gerrit for | |
| 22:27:34 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: use domain capabilities to get supported device models https://review.opendev.org/666915 | |
| 22:27:34 | openstackgerrit | sean mooney proposed openstack/nova master: Add transform_image_metadata request filter https://review.opendev.org/665775 | |
| #openstack-nova - 2019-09-04 | |||
| 00:27:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |
| 00:27:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021 | |
| 00:27:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration https://review.opendev.org/672595 | |
| 01:00:08 | openstackgerrit | Merged openstack/nova master: re-calculate provider mapping during migration https://review.opendev.org/655112 | |
| 02:39:55 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |
| 02:39:56 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021 | |
| 02:39:56 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration https://review.opendev.org/672595 | |
| 04:15:11 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add delete_on_termination to volume-attach API https://review.opendev.org/673133 | |
| 05:10:26 | cervigni | Hello, I have a dual socket server. Each cpu with two numa nodes. I would like to have the host to have a cpu overallocation of 2.0. At the same time I would like each flavor to stay bounded to its own numa node | |
| 05:10:32 | cervigni | Is there a way to achieve that? This would mean 2x instances on each numa nodes | |
| 05:10:36 | cervigni | I did not find a way to do that | |
| 05:10:51 | cervigni | This is because each of the CPU is connected on the pci-e bus on a GPU | |
| 05:11:03 | cervigni | and i need to respect the numa nodes configuration | |
| 05:39:05 | openstackgerrit | Dustin Cowles proposed openstack/nova master: Provider Config File: YAML file loading and schema validation https://review.opendev.org/673341 | |
| 05:39:05 | openstackgerrit | Dustin Cowles proposed openstack/nova master: WIP: Provider Config File: Public method to retrieve custom resources https://review.opendev.org/676029 | |
| 05:39:06 | openstackgerrit | Dustin Cowles proposed openstack/nova master: WIP: Provider Config File: Update provider tree with new custom resources https://review.opendev.org/676522 | |
| 06:30:07 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove unused methods https://review.opendev.org/679918 | |
| 06:49:30 | openstackgerrit | Yongli He proposed openstack/python-novaclient master: Microversion 2.78 - show server topology https://review.opendev.org/670790 | |
| 06:58:46 | cervigni | guys, could you help me find out if this is a bug before I submit something stupid on Launchpad? | |
| 06:58:48 | cervigni | https://pastebin.com/SfD63LgJ | |
| 06:59:35 | cervigni | it seems that a flavour configured as in the logs, continusly allocate cores only on the first numa node, instead of checking the actual cpus already allocated in that node | |
| 07:02:28 | gibi | cervigni: do you want dedicated physical cpu cores for your servers? | |