| opendevreview | melanie witt proposed openstack/nova master: Increase wait retries for resize reschedule functional test https://review.opendev.org/c/openstack/nova/+/985741 | 00:08 |
|---|---|---|
| melwitt | gmaan: just an update, the graceful shutdown was unrelated and was just the test cleanup happening after the wait for server state failed ^ | 00:09 |
| gmaan | melwitt: ohk, thanks for fix, +2 | 01:00 |
| melwitt | thanks gmaan | 01:01 |
| *** bauzas4 is now known as bauzas | 02:07 | |
| opendevreview | Rico Lin proposed openstack/nova master: compute: add [compute] skip_inventory_in_use_errors https://review.opendev.org/c/openstack/nova/+/985750 | 06:25 |
| opendevreview | Rico Lin proposed openstack/nova master: compute: add skip_inventory_in_use_errors opt https://review.opendev.org/c/openstack/nova/+/985750 | 06:26 |
| opendevreview | Merged openstack/nova master: Increase wait retries for resize reschedule functional test https://review.opendev.org/c/openstack/nova/+/985741 | 08:01 |
| elodilles | bauzas Uggla : i know this is PTG week, but i've prepared nova release patches, mainly because of we could do a final 2024.2 Dalmatian release before it moves to EOL. could you please review them? https://review.opendev.org/q/project:openstack/releases+is:open+intopic:nova | 09:02 |
| Uggla | Hi elodilles, I'm gonna have a look | 09:03 |
| elodilles | thx in advance o/ | 09:06 |
| opendevreview | ribaudr proposed openstack/nova master: ironic: Optimize get_num_instances to avoid unnecessary API calls https://review.opendev.org/c/openstack/nova/+/985785 | 09:26 |
| bauzas | elodilles: ack, will look | 09:32 |
| elodilles | thanks, too o/ | 09:48 |
| Uggla | bauzas, elodilles, if you can have a look at 985791: Add Nova deadlines to the 2026.2 Hibiscus schedule | https://review.opendev.org/c/openstack/releases/+/985791 (no hurries) | 10:15 |
| elodilles | Uggla: ack, will do | 10:29 |
| opendevreview | sean mooney proposed openstack/nova master: [dnm] testing with python 3.14 https://review.opendev.org/c/openstack/nova/+/985802 | 11:22 |
| sean-k-mooney | Uggla: gmaan sambork so i hacked up some py 3.14 testing yesteday and got some interesting result on https://review.opendev.org/c/openstack/devstack/+/985735 | 11:23 |
| sean-k-mooney | we can boot vms but some things fail | 11:24 |
| sean-k-mooney | for example some of the novnc tests | 11:24 |
| sean-k-mooney | the dnm to nova above shoudl give us better results fro our edgecases | 11:24 |
| sean-k-mooney | basicly i have a WIP serise for devtack to use uv to provide python and replace pip with uv pip | 11:25 |
| sean-k-mooney | what that allows use to do is use basicly any python verion on any distro within reason | 11:25 |
| sean-k-mooney | so with that dnm all our jobs regrdless of the disto will run on python 3.14 and give ues a good overviewr of compatiablity | 11:26 |
| sean-k-mooney | gibi: tkajinam sambork so the novnc issue iw the pikel issue we were discussing in the eventlet removeal room https://zuul.opendev.org/t/openstack/build/6f2857af77aa41eabb9f28a077081d89/log/controller/logs/screen-n-novnc-cell1.txt#16 | 11:27 |
| sean-k-mooney | we can see that tempest.api.compute.volumes.test_attach_volume.AttachVolumeMultiAttachTest.test_snapshot_volume_backed_multiattach and other complex test passed so for the most part we seam to be in a relitively good place | 11:32 |
| sambork | nice findings, I'm curious if this will pass with threading mode (because patch for proxies runing with threading are still under review https://review.opendev.org/c/openstack/nova/+/976089) | 11:55 |
| sean-k-mooney | you could add a second dnm on top of your patch | 11:55 |
| sean-k-mooney | you just need to depend on the devstack dnm | 11:55 |
| sean-k-mooney | but ya im not sure if the pikel issue is eventlet related or not | 11:56 |
| sean-k-mooney | sambork: or actully once my currnt dnm reports back | 11:56 |
| sean-k-mooney | i can rebase it on yoru review | 11:56 |
| sean-k-mooney | i just eamiled the list so other project can tyr this themselve if they want | 11:57 |
| elodilles | Uggla: Nova deadlines patch LGTM, i've +2'd it >>> https://review.opendev.org/c/openstack/releases/+/985791 | 12:02 |
| elodilles | bauzas Uggla : i've corrected the version bump on the epoxy release patch, can you please revisit that? https://review.opendev.org/c/openstack/releases/+/985651 | 12:03 |
| sean-k-mooney | elodilles: im not sure the ptg dicussion for that has happend yet https://etherpad.opendev.org/p/nova-2026.2-ptg#L179 | 12:03 |
| sean-k-mooney | elodilles: if it did there were not any notes taken | 12:03 |
| sean-k-mooney | i left some comment on it yesterday for whenever that happens | 12:04 |
| bauzas | elodilles: ack | 12:04 |
| elodilles | sean-k-mooney: it was discussed on Monday | 12:04 |
| elodilles | sean-k-mooney: and the notes are at the end of the lines o:) | 12:04 |
| sean-k-mooney | oh well no agreement was recrored | 12:04 |
| sean-k-mooney | the light green? | 12:05 |
| elodilles | yes | 12:05 |
| sean-k-mooney | because that just loosk liek comemnt folks had added | 12:05 |
| sean-k-mooney | wiht no agreement recorreded | 12:05 |
| 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 |
| sean-k-mooney | ack i was questioning the spec deadline | 12:07 |
| sean-k-mooney | but im not agents the dates over all | 12:07 |
| 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:08 |
| sean-k-mooney | but it effectily put the spec deadlien at the half way point of the cyle instead of 2/3rd | 12:09 |
| sean-k-mooney | which is fine as long as we also apply that to blueprint and we adverise ti to folks early | 12:09 |
| elodilles | sean-k-mooney: there were no hard opinions afair, so maybe this can be negotiated further | 12:10 |
| 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 |
| 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:16 |
| 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:17 |
| 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 |
| bauzas | sean-k-mooney: feel free to chime in https://review.opendev.org/c/openstack/releases/+/985791 | 12:18 |
| Uggla | bauzas 👍 | 12:18 |
| *** ykarel_ is now known as ykarel | 13:29 | |
| opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | 14:44 |
| opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | 14:47 |
| tkajinam | mhen, ^^^ I've updated the spec to capture the firmware descriptor hack | 15:16 |
| 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:17 |
| opendevreview | sean mooney proposed openstack/nova master: [dnm] testing with python 3.14 https://review.opendev.org/c/openstack/nova/+/985802 | 15:22 |
| tkajinam | oh I didn't notice that I've been holding the moderator role | 16:07 |
| tkajinam | (probably I got it because I joined first today... | 16:07 |
| clarkb | yes the first person to join gets it. You can give it to someone else | 16:07 |
| tkajinam | I hope I transferred it to Uggla correctly ... | 16:08 |
| Uggla | tkajinam seems ok thanks | 16:08 |
| tkajinam | Uggla, is it still continued, right ? | 16:09 |
| Uggla | tkajinam yep no pb. | 16:09 |
| tkajinam | I left the meeting and saw message saying "the others are all leaving" | 16:09 |
| tkajinam | which scared me really ... :-( | 16:09 |
| Uggla | tkajinam no worries we are all in the room, it's working fine. | 16:09 |
| tkajinam | that's good | 16:10 |
| tkajinam | leaving now. will try to attend the attestation session tomorrow (but no guarantee) | 16:10 |
| Uggla | tkajinam, thanks Takashi, yes please rest. | 16:10 |
| opendevreview | Merged openstack/nova master: [py313-threading]Reenable last scatter-gather unit test https://review.opendev.org/c/openstack/nova/+/984349 | 16:31 |
| opendevreview | Merged openstack/nova master: [py313-threading]Reenable test_show_simple_tenant_usage_policy https://review.opendev.org/c/openstack/nova/+/984606 | 16:32 |
| 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:28 |
| gibi | melwitt: I'm always happy to review stabiliziation patches | 17:29 |
| 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:30 |
| gibi | :) | 17:48 |
| 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 | 17:51 |
| * stephenfin calls it | 17:51 | |
| 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:22 |
| 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:31 |
| melwitt | understand why | 18:31 |
| 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 |
| sean-k-mooney | dont worrry about messing up ming beu totally fine to do it in your onw patch too | 18:32 |
| sean-k-mooney | ok so is the limitaiotn with ovn | 18:33 |
| melwitt | this isn't super important obviously but just wanted to let you know what I did haha | 18:33 |
| sean-k-mooney | we could jsut swap to ml2 ovs | 18:34 |
| sean-k-mooney | like the alt config job | 18:34 |
| melwitt | sometimes ip route list finds host_ip_iface=enX0 sometimes it finds host_ip_iface=ens3 | 18:34 |
| sean-k-mooney | that depens on the disto/kernle | 18:34 |
| sean-k-mooney | the systemd/bios dev name stuff | 18:35 |
| 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:35 |
| sean-k-mooney | yes we moved the ceph jobs ot debian 13 becuase of some qemu/ceph isues | 18:36 |
| sean-k-mooney | basiclly to get newer versions with less bugs | 18:36 |
| sean-k-mooney | so this is debian 13 | 18:36 |
| melwitt | ok, so my next experiment can be configuring ml2 ovs in my dnm patch | 18:36 |
| melwitt | that's helpful to know, thanks | 18:36 |
| sean-k-mooney | you coudl do that or you could enable ceph in the nova alt config job | 18:36 |
| sean-k-mooney | but eihter would worth a try | 18:37 |
| melwitt | ah ok | 18:37 |
| sean-k-mooney | the alt config job is already ml2 ovs i bleive | 18:37 |
| sean-k-mooney | as is nova next | 18:37 |
| sean-k-mooney | but one has legacy ip tables and hte other the ovs firewall driver | 18:38 |
| melwitt | gotcha | 18:38 |
| sean-k-mooney | melwitt: the other thin we may or many not need too do is modify the multi node bridge | 18:41 |
| melwitt | that is uncharted territory for me but I will keep in mind | 18:42 |
| 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 |
| sean-k-mooney | so that we get a flat l2 network that we can shove vlans through | 18:42 |
| sean-k-mooney | we might need to do somethign like assign ipv6 ips to that bridge and use those instead | 18:43 |
| melwitt | is that something that's done in devstack? | 18:43 |
| sean-k-mooney | yes | 18:43 |
| sean-k-mooney | well no | 18:43 |
| sean-k-mooney | in the devstack job | 18:43 |
| melwitt | oh interesting | 18:43 |
| sean-k-mooney | its done by a role in zuul-jobs | 18:43 |
| melwitt | I'll go look at it | 18:43 |
| melwitt | ahhh roles, that explains why I never saw anything | 18:44 |
| sean-k-mooney | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/multi-node-bridge | 18:44 |
| sean-k-mooney | ah its using ovs in the upstream verison i have a version of this that uses linux bridge | 18:44 |
| melwitt | neat | 18:44 |
| 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 |
| sean-k-mooney | the swtich is the contoler and the peers are the subnode | 18:45 |
| sean-k-mooney | that use for cretating the tunnels and bridges | 18:45 |
| sean-k-mooney | by https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/multi-node-bridge | 18:46 |
| 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 |
| melwitt | I never knew what that did. that's cool | 18:46 |
| 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:48 |
| sean-k-mooney | but like this role in some from has existied since we use jenkins | 18:49 |
| sean-k-mooney | melwitt: so just looking at the job run https://zuul.opendev.org/t/openstack/build/dcc395a124c04f4fbc3368ddf97400d3/log/job-output.txt | 18:49 |
| sean-k-mooney | what exactly was the issues the ovn setup ? | 18:50 |
| sean-k-mooney | becasue the interfac echeted or soemthin else | 18:50 |
| 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 |
| sean-k-mooney | :) as a compute person blamin gnetworkign and storage first alwasy means less work | 18:51 |
| sean-k-mooney | but ya ill take a look quickly and ssee if i can see teh actual failure | 18:52 |
| 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:52 |
| 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 |
| sean-k-mooney | so we have a role that does that copy | 18:54 |
| melwitt | at that point I didn't know what to do | 18:54 |
| sean-k-mooney | but we dont normally need a cert for the compute | 18:54 |
| sean-k-mooney | we just need the ca | 18:55 |
| sean-k-mooney | so it trust the contoler | 18:55 |
| melwitt | I got a cert validation error when subnode tried to contact controller so that's why I did it. oh, ok | 18:55 |
| melwitt | not sure why what was there originally didn't work. maybe it was a one-off | 18:55 |
| sean-k-mooney | maybe or maybe its because of how the name/ip is included in the cert | 18:56 |
| sean-k-mooney | like if we are connetiv via the ipv6 adress rather then the name we might need to do soemthign differnt | 18:57 |
| melwitt | yeah the complaint mentioned the commonName not matching or something like that | 18:57 |
| sean-k-mooney | oh https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/multi-node-hosts-file | 18:57 |
| sean-k-mooney | so that only adds the ipv4 adresses to /etc/hosts | 18:57 |
| sean-k-mooney | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/multi-node-hosts-file/tasks/main.yaml so maybe that a factor | 18:58 |
| melwitt | hm ok | 18:58 |
| sean-k-mooney | what that does is loop over all the hsot in the inventory adn update /etc/host so that contoller maps to the correct ip | 18:59 |
| sean-k-mooney | that may or may not be related jsut noticed the doc says its only for ipv4 which the code confirms | 18:59 |
| melwitt | I see | 19:01 |
| sean-k-mooney | thisd does nto prove anyting but if you look at the zuul-info.* files https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_dcc/openstack/dcc395a124c04f4fbc3368ddf97400d3/zuul-info/index.html | 19:05 |
| sean-k-mooney | what i do notice is the compute seams to have much hihger latency then the contoler | 19:05 |
| sean-k-mooney | they both have the saem default route | 19:07 |
| sean-k-mooney | btu they took difent path back to open dev (ill ignore the fact the ipv4 trace rotes is actully v6 in both) | 19:07 |
| sean-k-mooney | we also see fe80::ac5a:77ff:fe03:adb2 dev ens3 lladdr ae:5a:77:03:ad:b2 router DELAY vs fe80::3457:e8ff:fe88:9852 dev ens3 lladdr 36:57:e8:88:98:52 router REACHABLE | 19:08 |
| sean-k-mooney | both those got a routabel ip in teh same ipv6 subnet 2001:41d0:302:1000::cbc/56 s | 19:09 |
| sean-k-mooney | so they shoudl be able to comunicate fine | 19:09 |
| melwitt | :/ | 19:10 |
| sean-k-mooney | https://[2001:41d0:302:1000::1ab]/identity | 19:10 |
| sean-k-mooney | so that what its trying to conenct too | 19:10 |
| sean-k-mooney | but that is not the adress of the contoler | 19:11 |
| sean-k-mooney | that is the adress of the compute | 19:11 |
| sean-k-mooney | so the compute is trying to conenct to its own ipv6 adress to talk to keystone | 19:11 |
| sean-k-mooney | and that is because SERVICE_HOST | 19:11 |
| sean-k-mooney | is not set properly | 19:12 |
| sean-k-mooney | your setting SERVICE_HOST: "" | 19:13 |
| sean-k-mooney | that will work on singel node | 19:13 |
| sean-k-mooney | but we actully need to set that to the ipv6 adress of the contoler | 19:13 |
| melwitt | oh, bleh ok. | 19:13 |
| sean-k-mooney | or the host naem in /etc/hosts need to resove to the ipv6 adres | 19:13 |
| melwitt | I just copied it from the base ipv6 job out of desperation | 19:14 |
| melwitt | ok. sorry about that | 19:14 |
| sean-k-mooney | dont be sorry. but that why i didnt set service host in my orgianl patch | 19:16 |
| sean-k-mooney | the orcstarte devstack role shoudl populate that for us | 19:17 |
| melwitt | I wonder why does the base job do that then | 19:17 |
| sean-k-mooney | but it may or may not work out of the box for ipv6 | 19:17 |
| sean-k-mooney | melwitt: my gess it its a hack because it use the ipv4 adress or similar | 19:17 |
| sean-k-mooney | but lets find out | 19:17 |
| opendevreview | melanie witt proposed openstack/nova master: DNM test ceph ipv6 https://review.opendev.org/c/openstack/nova/+/984623 | 19:19 |
| sean-k-mooney | so i tought it was configred via https://github.com/openstack/devstack/blob/03ece8f88040be9b0b14dd1cfe93076ad2419a80/playbooks/pre.yaml#L37 | 19:20 |
| sean-k-mooney | but no... | 19:20 |
| sean-k-mooney | ah https://github.com/openstack/devstack/blob/03ece8f88040be9b0b14dd1cfe93076ad2419a80/.zuul.yaml#L514 | 19:22 |
| sean-k-mooney | so devstack-minimal is doing SERVICE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}" | 19:22 |
| sean-k-mooney | melwitt: can you try changing that to SERVICE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv6'] }}" im goign to doubel check that thats a thing | 19:22 |
| melwitt | sure | 19:23 |
| sean-k-mooney | ok that will not work but we can get the ip adress in a difennt place | 19:24 |
| sean-k-mooney | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_dcc/openstack/dcc395a124c04f4fbc3368ddf97400d3/zuul-info/inventory.yaml | 19:24 |
| sean-k-mooney | is the inventory file and that has private_ipv6: null | 19:24 |
| melwitt | ah | 19:25 |
| sean-k-mooney | but if we look in teh ansibel fact https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_dcc/openstack/dcc395a124c04f4fbc3368ddf97400d3/zuul-info/host-info.controller.yaml | 19:26 |
| sean-k-mooney | we defnilly have access to the ip | 19:26 |
| sean-k-mooney | i think this will work. one sec whil i type it out | 19:26 |
| sean-k-mooney | SERVICE_HOST: ""{{hostvars['controller']['ansible_defult_ipv6']['address']}}" | 19:28 |
| sean-k-mooney | well - the extra " | 19:28 |
| sean-k-mooney | SERVICE_HOST: "{{hostvars['controller']['ansible_defult_ipv6']['address']}}" | 19:28 |
| melwitt | yes I will edit the typos :) | 19:28 |
| sean-k-mooney | you will also need to set it for the subvar | 19:29 |
| melwitt | ack | 19:29 |
| sean-k-mooney | we can proably fix this in the devstack defintion to be based on if you have selecte ipv4 or ipv6 for the serivce ip later | 19:30 |
| sean-k-mooney | in the job defintion we are seting SERVICE_IP_VERSION: 6 so we have something to switch off | 19:31 |
| sean-k-mooney | withthat said if i look at the job vriable for the compute | 19:31 |
| sean-k-mooney | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_dcc/openstack/dcc395a124c04f4fbc3368ddf97400d3/zuul-info/inventory.yaml | 19:31 |
| sean-k-mooney | i see a lot of other ip v4 stuff there but we can revisti that if needed | 19:32 |
| opendevreview | melanie witt proposed openstack/nova master: DNM test ceph ipv6 https://review.opendev.org/c/openstack/nova/+/984623 | 19:32 |
| sean-k-mooney | melwitt: as an asside we started looking at this because we wanted to test a patch that was related to it | 19:33 |
| sean-k-mooney | melwitt: do you recall if we you knwo merged that bug fix? | 19:33 |
| sean-k-mooney | the libvirt migration one | 19:33 |
| melwitt | right. no we did not merge it yet and I have been trying to make this work in order to verify it | 19:34 |
| sean-k-mooney | ack | 19:34 |
| melwitt | I'm not opposed to merging it without verification but it would be really great to be able to | 19:34 |
| sean-k-mooney | oh ya i agree it would be good to have it | 19:34 |
| sean-k-mooney | i just lost context on where we were at with the patch | 19:34 |
| melwitt | after seeing that XML ipv6 brackets thing, I am feeling like I really want to see this work haha | 19:35 |
| sean-k-mooney | yep | 19:35 |
| sean-k-mooney | ok im going to wrap for today | 19:35 |
| melwitt | it looks fine to me. just wanted to see if I could do this. if not, I'll just review it without | 19:36 |
| sean-k-mooney | ill try and remember to check the resutls of tha trun but feel free to ping me to take another look | 19:36 |
| melwitt | cool thanks for the help | 19:36 |
| sean-k-mooney | melwitt: by the way i said this before but there is currently no ipv6 + ceph covage anywhere. i dont even think there is singel node | 19:37 |
| sean-k-mooney | so defintly nice ot fix that at some point | 19:37 |
| melwitt | ++ | 19:37 |
| isaacvicente[m] | hi guys o/ i would like to start solving this bug: https://bugs.launchpad.net/nova/+bug/2035911 | 19:39 |
| isaacvicente[m] | given the last time it was assigned to someone, its ok to assign to myself? i replied on the bug but got no reponse | 19:39 |
| melwitt | isaacvicente[m]: yeah I would go ahead and assign it to yourself | 19:40 |
| isaacvicente[m] | nice, i started looking into it, and i wonder where I would do the changes. Trying to understand better the bug and the code base itself I asked chatgpt-codex-5.3 where the changes would be. It said that drivers under nova/virt/libvirt/volumes has two functions: connect_volume and disconnect_volume. I would then add the os-brick context manager guard_connections on those functions. I'm not sure if this is the right | 19:48 |
| isaacvicente[m] | direction. Does it make sense? | 19:48 |
| isaacvicente[m] | * nice, i started looking into it, and i wonder where I would do the changes. Trying to understand better the bug and the code base itself I asked chatgpt-codex-5.3 where the changes would be. It said that drivers under nova/virt/libvirt/volumes has two functions: connect_volume and disconnect_volume. I would then add the os-brick context manager guard_connection on those functions. I'm not sure if this is the right | 19:49 |
| isaacvicente[m] | direction. Does it make sense? | 19:49 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!