| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-22 | |||
| 12:05:29 | sean-k-mooney | wiht no agreement recorreded | |
| 12:07:19 | elodilles | indeed, it is not commented at 'AGREED' section, but otherwise based on the discussion the commented dates were agreed, but correct me Uggla if i'm wrong | |
| 12:07:43 | sean-k-mooney | ack i was questioning the spec deadline | |
| 12:07:57 | sean-k-mooney | but im not agents the dates over all | |
| 12:08:53 | sean-k-mooney | we had less time for it spec last cycle (i..e it was before m2) so this proposal is just repeating that that patten again this cycle | |
| 12:09:28 | sean-k-mooney | but it effectily put the spec deadlien at the half way point of the cyle instead of 2/3rd | |
| 12:09:50 | sean-k-mooney | which is fine as long as we also apply that to blueprint and we adverise ti to folks early | |
| 12:10:02 | elodilles | sean-k-mooney: there were no hard opinions afair, so maybe this can be negotiated further | |
| 12:16:12 | sean-k-mooney | the only real point i wanted to contibut is spec and blueprint approve deadline shoudl be the same, and tell peopel early because several contibutors in other poejct that wanted to do cross project things with nova didnt knwo we had the deadline in decemeber for it last cycle | |
| 12:16:48 | sean-k-mooney | i had to tell multiple peopel that they missed the spec deadlien in late decemebr early and early january because they were exectign m2 | |
| 12:17:49 | sean-k-mooney | so as long as we tell peopel in advance then thats fine. just uodatign the secheudler isnt enouch to "tell peopel" becausemost project dont recrod the deadliens in the schdule and dont expect that to be where its comunicated | |
| 12:18:01 | bauzas | Uggla: gentle reminder that I won't be able to join the nova sessions until 3pm UTC (hopefully), maybe a bit later | |
| 12:18:47 | bauzas | sean-k-mooney: feel free to chime in https://review.opendev.org/c/openstack/releases/+/985791 | |
| 12:18:52 | Uggla | bauzas 👍 | |
| 14:44:15 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | |
| 14:47:05 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | |
| 15:16:56 | tkajinam | mhen, ^^^ I've updated the spec to capture the firmware descriptor hack | |
| 15:17:19 | tkajinam | it seems that the required content is available in c10s and even c9s (!!!) while it's not in ubuntu 24.04 or even 26.04 :-( | |
| 15:22:00 | opendevreview | sean mooney proposed openstack/nova master: [dnm] testing with python 3.14 https://review.opendev.org/c/openstack/nova/+/985802 | |
| 16:07:15 | tkajinam | oh I didn't notice that I've been holding the moderator role | |
| 16:07:29 | tkajinam | (probably I got it because I joined first today... | |
| 16:07:38 | clarkb | yes the first person to join gets it. You can give it to someone else | |
| 16:08:39 | tkajinam | I hope I transferred it to Uggla correctly ... | |
| 16:08:55 | Uggla | tkajinam seems ok thanks | |
| 16:09:09 | tkajinam | Uggla, is it still continued, right ? | |
| 16:09:21 | Uggla | tkajinam yep no pb. | |
| 16:09:27 | tkajinam | I left the meeting and saw message saying "the others are all leaving" | |
| 16:09:49 | tkajinam | which scared me really ... :-( | |
| 16:09:59 | Uggla | tkajinam no worries we are all in the room, it's working fine. | |
| 16:10:06 | tkajinam | that's good | |
| 16:10:07 | tkajinam | leaving now. will try to attend the attestation session tomorrow (but no guarantee) | |
| 16:10:44 | Uggla | tkajinam, thanks Takashi, yes please rest. | |
| 16:31:52 | opendevreview | Merged openstack/nova master: [py313-threading]Reenable last scatter-gather unit test https://review.opendev.org/c/openstack/nova/+/984349 | |
| 16:32:14 | opendevreview | Merged openstack/nova master: [py313-threading]Reenable test_show_simple_tenant_usage_policy https://review.opendev.org/c/openstack/nova/+/984606 | |
| 17:28:13 | melwitt | gibi: thank you for the review on https://review.opendev.org/c/openstack/nova/+/985741, I am very motivated to try and stabilize the CI 😆 | |
| 17:29:25 | gibi | melwitt: I'm always happy to review stabiliziation patches | |
| 17:30:42 | stephenfin | gibi: I checked and yeah, I have a WIP commit from 22-Jan in my local oslo.service repo where I started adding a LauncherBase command (and some others) 😅 | |
| 17:48:16 | gibi | :) | |
| 17:51:09 | stephenfin | And this is the first thing that comes to mind wrt the requested oslo.service issue https://review.opendev.org/c/openstack/oslo.service/+/985859 I'd prefer to rework this to make that more natural but it's emmintly doable | |
| 18:22:17 | sean-k-mooney | gibi: sambork so i said as much in the patch but the good news is the novnc proxy fails on 3.14 with eventlet but works in threaded mode | |
| 18:31:20 | melwitt | understand why | |
| 18:31:20 | melwitt | sean-k-mooney: this is random but I spent some time trying to get multinode ipv6 to work to look at ceph live migration, I made my own page bc I didn't want to mess yours up too much https://review.opendev.org/c/openstack/nova/+/984623 I come to the conclusion that this is known to not be possible (https://opendev.org/openstack/neutron/src/commit/2bc1bcc675ded515c8dd8da5e513010f6cb59794/zuul.d/tempest-singlenode.yaml#L744) but I don't | |
| 18:32:07 | melwitt | on the subnode, the interface that's found to support ipv6 just will not route to the controller and I don't get why | |
| 18:32:56 | sean-k-mooney | dont worrry about messing up ming beu totally fine to do it in your onw patch too | |
| 18:33:48 | sean-k-mooney | ok so is the limitaiotn with ovn | |
| 18:33:53 | melwitt | this isn't super important obviously but just wanted to let you know what I did haha | |
| 18:34:06 | sean-k-mooney | we could jsut swap to ml2 ovs | |
| 18:34:12 | sean-k-mooney | like the alt config job | |
| 18:34:35 | melwitt | sometimes ip route list finds host_ip_iface=enX0 sometimes it finds host_ip_iface=ens3 | |
| 18:34:50 | sean-k-mooney | that depens on the disto/kernle | |
| 18:35:05 | sean-k-mooney | the systemd/bios dev name stuff | |
| 18:35:26 | melwitt | ah ok. yeah I ended up having to make DNM https://review.opendev.org/c/openstack/devstack/+/984605 to handle was it debian? I can't remember | |
| 18:36:02 | sean-k-mooney | yes we moved the ceph jobs ot debian 13 becuase of some qemu/ceph isues | |
| 18:36:16 | sean-k-mooney | basiclly to get newer versions with less bugs | |
| 18:36:24 | sean-k-mooney | so this is debian 13 | |
| 18:36:33 | melwitt | ok, so my next experiment can be configuring ml2 ovs in my dnm patch | |
| 18:36:38 | melwitt | that's helpful to know, thanks | |
| 18:36:58 | sean-k-mooney | you coudl do that or you could enable ceph in the nova alt config job | |
| 18:37:09 | sean-k-mooney | but eihter would worth a try | |
| 18:37:24 | melwitt | ah ok | |
| 18:37:38 | sean-k-mooney | the alt config job is already ml2 ovs i bleive | |
| 18:37:46 | sean-k-mooney | as is nova next | |
| 18:38:03 | sean-k-mooney | but one has legacy ip tables and hte other the ovs firewall driver | |
| 18:38:06 | melwitt | gotcha | |
| 18:41:31 | sean-k-mooney | melwitt: the other thin we may or many not need too do is modify the multi node bridge | |
| 18:42:07 | melwitt | that is uncharted territory for me but I will keep in mind | |
| 18:42:36 | sean-k-mooney | melwitt: if you have not looked at the multi node job in detail, it create linuxor ovs? briges on each of the hosts and and interconenct them with vxlan tunnels | |
| 18:42:54 | sean-k-mooney | so that we get a flat l2 network that we can shove vlans through | |
| 18:43:20 | sean-k-mooney | we might need to do somethign like assign ipv6 ips to that bridge and use those instead | |
| 18:43:31 | melwitt | is that something that's done in devstack? | |
| 18:43:35 | sean-k-mooney | yes | |
| 18:43:43 | sean-k-mooney | well no | |
| 18:43:47 | sean-k-mooney | in the devstack job | |
| 18:43:53 | melwitt | oh interesting | |
| 18:43:55 | sean-k-mooney | its done by a role in zuul-jobs | |
| 18:43:58 | melwitt | I'll go look at it | |
| 18:44:14 | melwitt | ahhh roles, that explains why I never saw anything | |
| 18:44:15 | sean-k-mooney | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/multi-node-bridge | |
| 18:44:45 | sean-k-mooney | ah its using ovs in the upstream verison i have a version of this that uses linux bridge | |
| 18:44:55 | melwitt | neat | |
| 18:45:29 | sean-k-mooney | if you have ever looked at the multi node nodeset you will see https://github.com/openstack/devstack/blob/master/.zuul.yaml#L133-L140 | |
| 18:45:47 | sean-k-mooney | the swtich is the contoler and the peers are the subnode | |
| 18:45:55 | sean-k-mooney | that use for cretating the tunnels and bridges | |
| 18:46:06 | sean-k-mooney | by https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/multi-node-bridge | |
| 18:46:32 | sean-k-mooney | so its not a full mesh but a set of point to point lings between the conotler node and the rest | |
| 18:46:55 | melwitt | I never knew what that did. that's cool | |
| 18:48:59 | sean-k-mooney | so i dont recall all the history but i knwo we use that to test vlan network sbut i belive its orgial use was to make sure we just had l2 connectivity betweeen each fo the subnodes as we coudl not alwasy depend on that | |
| 18:49:17 | sean-k-mooney | but like this role in some from has existied since we use jenkins | |
| 18:49:56 | sean-k-mooney | melwitt: so just looking at the job run https://zuul.opendev.org/t/openstack/build/dcc395a124c04f4fbc3368ddf97400d3/log/job-output.txt | |
| 18:50:08 | sean-k-mooney | what exactly was the issues the ovn setup ? | |
| 18:50:28 | sean-k-mooney | becasue the interfac echeted or soemthin else | |
| 18:51:11 | melwitt | tbh I don't really know other than the compute1 could not get to the /identity url on the controller. and I assumed that meant some aspect of networking was not connected somehow | |
| 18:51:49 | sean-k-mooney | :) as a compute person blamin gnetworkign and storage first alwasy means less work | |
| 18:52:05 | sean-k-mooney | but ya ill take a look quickly and ssee if i can see teh actual failure | |
| 18:52:39 | melwitt | the first problem was on compute1 it would never find a ipv6 interface because the awk command or whatever was not able to work with debian. so I made a devstack dnm patch for that. then it got farther to the point where compute1 is trying to do a very basic GET to /identity and it just hangs | |
| 18:54:08 | melwitt | the second problem was compute1 tls cert was for the controller commonName so it did not work (the code simply copied controller's certs to subnode) so I added to my dnm patch to make the subnode actually make a cert for itself, for its commonName. then it got farther and then crapped out trying to GET /identity | |
| 18:54:40 | sean-k-mooney | so we have a role that does that copy | |
| 18:54:44 | melwitt | at that point I didn't know what to do | |
| 18:54:58 | sean-k-mooney | but we dont normally need a cert for the compute | |
| 18:55:03 | sean-k-mooney | we just need the ca | |