| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-24 | |||
| 09:22:22 | bauzas | you can have placement aggregates | |
| 09:22:31 | bauzas | using compute node UUIDs | |
| 09:23:06 | bauzas | so, you could be able to provide flavors for each of them | |
| 09:23:14 | bauzas | but not AZs | |
| 09:25:29 | jkulik | bauzas: we have different racks of baremetal nodes assigned to different hostnames in nova. they are assigned to aggregates for the AZs in our case. that seemed to work | |
| 09:25:45 | bauzas | cool then | |
| 09:26:01 | jkulik | well yes and no ;) | |
| 09:26:25 | jkulik | we cannot sync those aggregates automatically to placement, because Nova doesn't support the case. | |
| 09:26:59 | jkulik | but it looks like that's just a matter of patching it (badly) to allow multiple resource providers/compute nodes for ironic | |
| 09:35:51 | bauzas | we discussed this a bit in the past but providing nova aggregates support for ironic wasn't pursued | |
| 09:36:10 | bauzas | as there are a ton of implications and some breaking changes | |
| 09:36:19 | bauzas | and then we moved to placement | |
| 09:36:47 | bauzas | the idea here is maybe to say we could use placement queries with some kind of prefilter that would be smarter | |
| 09:38:03 | jkulik | because the admin can target specific ironic nodes, I guess? makes sense. | |
| 09:38:14 | jkulik | thank you for helping me get a clearer picture on that | |
| 09:46:22 | gibi | lyarwood: I'm OK going with the python based solution in the machine_type series. We can optimize it later if we get reports about slowness | |
| 09:47:48 | lyarwood | gibi: ack, I'm going to respin the series later today, apologies for not getting to it just yet | |
| 09:48:01 | lyarwood | FWIW I'm about to admit defeat with the ephemeral encryption series | |
| 09:48:16 | lyarwood | there's just too much debt in the libvirt driver to land this in 2 weeks | |
| 09:48:39 | gibi | no problem, I also was slow responding | |
| 09:48:40 | lyarwood | and I've under estimated the required test coverage given the removal of some of that debt in this series | |
| 09:48:56 | gibi | lyarwood: ack, thanks for being upfront about that | |
| 10:14:56 | stephenfin | gibi: artom is on PTO so I'm going to address my own nits on https://review.opendev.org/c/openstack/nova/+/772748 to keep it moving | |
| 10:15:01 | stephenfin | is that okay? | |
| 10:15:23 | stephenfin | I can also fix up the next one since you agree with my comments | |
| 10:25:38 | Fl1nt | Hi there! | |
| 10:29:56 | Fl1nt | Quick question, let say I want to implement garbage collection/housekeeping and a mechanism to auto-balance my cluster when I had new nodes to a zone/cell/aggregate/whatever, is there already WIP or SIG working on this for nova? If not, would it be better to create a new project that work on nova/placement ressources or is it prefered to create it as a nova/placement feature? | |
| 10:34:38 | gibi | stephenfin: sure, it works for me | |
| 10:35:56 | gibi | Fl1nt: I'm not sure what is the status of https://wiki.openstack.org/wiki/Watcher but I think it has a scope you are looking for | |
| 10:37:14 | Fl1nt | gibi, perfect, if it already exist then I'll watch (no pun intended) it and contribut to it if it's not a living dead project ^^ | |
| 10:37:28 | gibi | :) | |
| 10:49:12 | gibi | brinzhang: I need stephenfin and melwitt to agree on the vnc password patch | |
| 10:51:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add 'socket' PCI NUMA affinity https://review.opendev.org/c/openstack/nova/+/772748 | |
| 10:51:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: scheduler: Add 'socket' PCI NUMA affinity policy trait https://review.opendev.org/c/openstack/nova/+/772749 | |
| 10:51:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Track host NUMA topology in PCI manager https://review.opendev.org/c/openstack/nova/+/774149 | |
| 10:51:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pci: implement the 'socket' NUMA affinity policy https://review.opendev.org/c/openstack/nova/+/772779 | |
| 10:51:35 | Fl1nt | thanks gibi that's absolutely what I was looking for! | |
| 10:51:50 | Fl1nt | thanks and cheers! | |
| 10:52:28 | gibi | Fl1nt: I'm happy that I could help | |
| 10:53:04 | belmoreira | one line patch review: https://review.opendev.org/c/openstack/nova/+/776428 Let me know if this makes sense. Created a lot of confusion some time ago :) | |
| 10:54:35 | gibi | belmoreira: make sense to me | |
| 11:39:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Add tests for insecure UEFI configuration https://review.opendev.org/c/openstack/nova/+/777367 | |
| 11:39:32 | stephenfin | bauzas: ^ | |
| 11:39:43 | bauzas | ta | |
| 11:39:51 | bauzas | will look | |
| 11:54:52 | gibi | sean-k-mooney: could you take a look on https://review.opendev.org/c/openstack/nova/+/750552 we have +2s from cores, but you had issues with the ipVersion vs ip_version in the spec. The impl goes with ipVersion. Is it a dealbreakre for you? | |
| 11:55:16 | sean-k-mooney | no its not | |
| 11:55:23 | sean-k-mooney | i prefer ip_version | |
| 11:55:28 | sean-k-mooney | but both work | |
| 11:56:05 | gibi | thanks, then I will approve the impl with ipVersion as there was no real preference in the existing attribute names for either ways | |
| 11:56:09 | sean-k-mooney | we coudl fix it with a follow up to the spec or code to bring them in line | |
| 11:56:33 | gibi | as far as I understand there is no definit line | |
| 11:56:34 | gibi | https://review.opendev.org/c/openstack/nova/+/750552/10/nova/virt/libvirt/config.py#3459 | |
| 11:56:56 | sean-k-mooney | i dont think we currently have any 2 word elemnts | |
| 11:57:02 | sean-k-mooney | at least not nova ones | |
| 11:57:30 | gibi | no, not nova ones | |
| 11:57:36 | gibi | but in general | |
| 11:57:50 | sean-k-mooney | well libvirt uses _ | |
| 11:58:07 | sean-k-mooney | <on_reboot>restart</on_reboot> | |
| 11:58:37 | sean-k-mooney | but its a minor nit | |
| 11:59:08 | sean-k-mooney | not a deal breaker i would just prefer to use _ when i extend it with the flavor info next cycle since i never got to it this cycle | |
| 11:59:41 | sean-k-mooney | acutlly it uses both | |
| 12:00:13 | sean-k-mooney | <currentMemory unit='KiB'>1048576</currentMemory> | |
| 12:00:28 | sean-k-mooney | so both are fine lets leave it as is | |
| 12:00:35 | sean-k-mooney | ill comment the same in the bug | |
| 12:00:39 | sean-k-mooney | *patch | |
| 12:02:11 | gibi | thanks | |
| 12:04:50 | sean-k-mooney | done | |
| 12:06:01 | sean-k-mooney | un related to that change but when we use https://www.openstack.org/xmlns/libvirt/nova/1.1 as a namespace url that is actully ment to be a vaild path to the xml schema | |
| 12:06:32 | sean-k-mooney | i dont know if we care to fix that at some point since we dont actully have a schema for the metadta xml elemnet just said i would note that in passing | |
| 12:11:44 | gibi | good point maybe we can fix that next cycle when we extend the schema further | |
| 12:13:07 | sean-k-mooney | ya not sure how we would fix it unless we put it in the docs and linked to the doc site or to the git repo on opendev.org | |
| 12:13:34 | sean-k-mooney | xml parsers can parse without a schema file they just cant validate it | |
| 12:13:41 | sean-k-mooney | well beyond syntax | |
| 12:14:22 | sean-k-mooney | but this is an internal api fro dubuging any way so its only ment to be read by humans not software | |
| 12:14:56 | tosky | hi nova people! It looks like the devstack-plugin-nfs tempest jobs are failing on ussuri only (see the last jobs on https://review.opendev.org/q/project:openstack/devstack-plugin-nfs+status:open ) | |
| 12:15:18 | tosky | whoami-rajat commented on one of the failures, it seems there is something weird on the nova side (please see the last comment here: https://review.opendev.org/c/openstack/devstack-plugin-nfs/+/763516/ ) | |
| 12:15:40 | tosky | are you aware of any NFS-related fix which hasn't been backported yet to ussuri? | |
| 12:15:47 | tosky | or at least can you please take a look? | |
| 12:15:49 | sean-k-mooney | i think lyarwood was tryign to get that to work again | |
| 12:15:56 | lyarwood | it's on my TODO list | |
| 12:16:09 | sean-k-mooney | tosky: we know of nfs related bugs | |
| 12:16:16 | lyarwood | tosky: nothing specific to ussuri btw | |
| 12:16:29 | tosky | right, so this may be another issue? | |
| 12:16:38 | lyarwood | tosky: yeah there are several with this codepath | |
| 12:16:46 | lyarwood | tosky: it's unique to NFS volumes | |
| 12:16:47 | sean-k-mooney | maybe the nfs backend is one of the most problematic we have support for currently | |
| 12:16:50 | lyarwood | tosky: and not maintained | |
| 12:16:54 | tosky | because really -ussuri seems to be consistently failing in the last builds | |
| 12:17:20 | lyarwood | kk well I can't think of anything that has landed since that could cause this tbh | |
| 12:17:35 | lyarwood | could someone write up a bug and I'll take a look early next week? | |
| 12:17:44 | tosky | sure | |
| 12:17:46 | lyarwood | thanks | |
| 12:17:59 | sean-k-mooney | looks like its the volumn snapshot tests that are failing | |
| 12:18:18 | sean-k-mooney | there are issue with snapshots and the nfs backend right | |
| 12:21:36 | sean-k-mooney | it looks like the nfs backend does not supprot snapshots of inuse volumen based on the error | |
| 12:22:57 | lyarwood | new test? | |
| 12:23:19 | sean-k-mooney | https://zuul.opendev.org/t/openstack/build/e9e69b9af21c414a83c0437894826178/log/controller/logs/screen-n-cpu.txt#48082 | |
| 12:23:29 | sean-k-mooney | Unknown base file: /opt/stack/data/nova/instances/_base/c4c416ed67a8e3a5f1de44029e480806bb6a55f9 | |
| 12:23:39 | whoami-rajat | sean-k-mooney: nfs driver supports it via blockrebase and blockcommit which is done by nova, but not sure exactly what you mean | |