| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-22 | |||
| 18:57:43 | sean-k-mooney | so that only adds the ipv4 adresses to /etc/hosts | |
| 18:58:24 | 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:34 | melwitt | hm ok | |
| 18:59:29 | 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:57 | sean-k-mooney | that may or may not be related jsut noticed the doc says its only for ipv4 which the code confirms | |
| 19:01:09 | melwitt | I see | |
| 19:05:08 | 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:44 | sean-k-mooney | what i do notice is the compute seams to have much hihger latency then the contoler | |
| 19:07:17 | sean-k-mooney | they both have the saem default route | |
| 19:07:47 | 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:08:23 | 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:09:14 | sean-k-mooney | both those got a routabel ip in teh same ipv6 subnet 2001:41d0:302:1000::cbc/56 s | |
| 19:09:48 | sean-k-mooney | so they shoudl be able to comunicate fine | |
| 19:10:07 | melwitt | :/ | |
| 19:10:42 | sean-k-mooney | https://[2001:41d0:302:1000::1ab]/identity | |
| 19:10:53 | sean-k-mooney | so that what its trying to conenct too | |
| 19:11:05 | sean-k-mooney | but that is not the adress of the contoler | |
| 19:11:27 | sean-k-mooney | that is the adress of the compute | |
| 19:11:48 | sean-k-mooney | so the compute is trying to conenct to its own ipv6 adress to talk to keystone | |
| 19:11:58 | sean-k-mooney | and that is because SERVICE_HOST | |
| 19:12:01 | sean-k-mooney | is not set properly | |
| 19:13:00 | sean-k-mooney | your setting SERVICE_HOST: "" | |
| 19:13:05 | sean-k-mooney | that will work on singel node | |
| 19:13:36 | sean-k-mooney | but we actully need to set that to the ipv6 adress of the contoler | |
| 19:13:44 | melwitt | oh, bleh ok. | |
| 19:13:59 | sean-k-mooney | or the host naem in /etc/hosts need to resove to the ipv6 adres | |
| 19:14:01 | melwitt | I just copied it from the base ipv6 job out of desperation | |
| 19:14:05 | melwitt | ok. sorry about that | |
| 19:16:26 | sean-k-mooney | dont be sorry. but that why i didnt set service host in my orgianl patch | |
| 19:17:00 | sean-k-mooney | the orcstarte devstack role shoudl populate that for us | |
| 19:17:13 | melwitt | I wonder why does the base job do that then | |
| 19:17:15 | sean-k-mooney | but it may or may not work out of the box for ipv6 | |
| 19:17:39 | sean-k-mooney | melwitt: my gess it its a hack because it use the ipv4 adress or similar | |
| 19:17:48 | sean-k-mooney | but lets find out | |
| 19:19:47 | opendevreview | melanie witt proposed openstack/nova master: DNM test ceph ipv6 https://review.opendev.org/c/openstack/nova/+/984623 | |
| 19:20:40 | sean-k-mooney | so i tought it was configred via https://github.com/openstack/devstack/blob/03ece8f88040be9b0b14dd1cfe93076ad2419a80/playbooks/pre.yaml#L37 | |
| 19:20:47 | sean-k-mooney | but no... | |
| 19:22:09 | sean-k-mooney | ah https://github.com/openstack/devstack/blob/03ece8f88040be9b0b14dd1cfe93076ad2419a80/.zuul.yaml#L514 | |
| 19:22:33 | sean-k-mooney | so devstack-minimal is doing SERVICE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}" | |
| 19:22:53 | 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:23:34 | melwitt | sure | |
| 19:24:18 | sean-k-mooney | ok that will not work but we can get the ip adress in a difennt place | |
| 19:24:21 | sean-k-mooney | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_dcc/openstack/dcc395a124c04f4fbc3368ddf97400d3/zuul-info/inventory.yaml | |
| 19:24:31 | sean-k-mooney | is the inventory file and that has private_ipv6: null | |
| 19:25:24 | melwitt | ah | |
| 19:26:00 | 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:12 | sean-k-mooney | we defnilly have access to the ip | |
| 19:26:44 | sean-k-mooney | i think this will work. one sec whil i type it out | |
| 19:28:15 | sean-k-mooney | SERVICE_HOST: ""{{hostvars['controller']['ansible_defult_ipv6']['address']}}" | |
| 19:28:41 | sean-k-mooney | well - the extra " | |
| 19:28:51 | sean-k-mooney | SERVICE_HOST: "{{hostvars['controller']['ansible_defult_ipv6']['address']}}" | |
| 19:28:53 | melwitt | yes I will edit the typos :) | |
| 19:29:45 | sean-k-mooney | you will also need to set it for the subvar | |
| 19:29:58 | melwitt | ack | |
| 19:30:18 | 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:31:22 | sean-k-mooney | in the job defintion we are seting SERVICE_IP_VERSION: 6 so we have something to switch off | |
| 19:31:41 | sean-k-mooney | withthat said if i look at the job vriable for the compute | |
| 19:31:43 | sean-k-mooney | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_dcc/openstack/dcc395a124c04f4fbc3368ddf97400d3/zuul-info/inventory.yaml | |
| 19:32:01 | sean-k-mooney | i see a lot of other ip v4 stuff there but we can revisti that if needed | |
| 19:32:43 | opendevreview | melanie witt proposed openstack/nova master: DNM test ceph ipv6 https://review.opendev.org/c/openstack/nova/+/984623 | |
| 19:33:22 | 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:32 | sean-k-mooney | melwitt: do you recall if we you knwo merged that bug fix? | |
| 19:33:43 | sean-k-mooney | the libvirt migration one | |
| 19:34:06 | 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:13 | sean-k-mooney | ack | |
| 19:34:16 | melwitt | I'm not opposed to merging it without verification but it would be really great to be able to | |
| 19:34:43 | sean-k-mooney | oh ya i agree it would be good to have it | |
| 19:34:59 | sean-k-mooney | i just lost context on where we were at with the patch | |
| 19:35:06 | melwitt | after seeing that XML ipv6 brackets thing, I am feeling like I really want to see this work haha | |
| 19:35:16 | sean-k-mooney | yep | |
| 19:35:23 | sean-k-mooney | ok im going to wrap for today | |
| 19:36:09 | 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:16 | 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:41 | melwitt | cool thanks for the help | |
| 19:37:19 | 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:41 | sean-k-mooney | so defintly nice ot fix that at some point | |
| 19:37:57 | melwitt | ++ | |
| 19:39:16 | isaacvicente[m] | hi guys o/ i would like to start solving this bug: https://bugs.launchpad.net/nova/+bug/2035911 | |
| 19:39:16 | 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:40:38 | melwitt | isaacvicente[m]: yeah I would go ahead and assign it to yourself | |
| 19:48:10 | 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:10 | isaacvicente[m] | direction. Does it make sense? | |
| 19:49:05 | 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:05 | isaacvicente[m] | direction. Does it make sense? | |
| #openstack-nova - 2026-04-23 | |||
| 00:58:55 | opendevreview | melanie witt proposed openstack/nova master: DNM test ceph ipv6 https://review.opendev.org/c/openstack/nova/+/984623 | |
| 02:09:31 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | |
| 09:01:53 | dougszu | sean-k-mooney - morning, the bug about ephemeral volume corruption during VM migration (https://bugs.launchpad.net/nova/+bug/2095173) has that been fixed in Nova by dropping the creation of a filesystem in the base image? | |
| 12:12:56 | lajoskatona | Uggla: Hi, today I have a topic for os-external-events vs Neutron notifier vs SDK (https://etherpad.opendev.org/p/nova-2026.2-ptg#L771), shall I ask to have it discussed before 1530UTC (1730 CEST) as I have to drop around that time ? | |
| 12:16:27 | Uggla | Hi lajoskatona, it should happen around 1400 / 1430UTC. So yes. | |
| 12:19:05 | lajoskatona | Uggla: thanks | |
| 12:53:05 | jkulik | How come n-api and n-scheduler require a cell DB? Is it just to be able to register as a compute service? | |
| 12:59:51 | sean-k-mooney | jkulik: its used for 2 thing | |
| 13:00:09 | sean-k-mooney | so cell 0 is where all the service entries for the global serviece live i..e the schdluer/api ecta | |
| 13:00:36 | jkulik | ah. cell0! thanks, I thought I'd have to use a productive cell | |
| 13:00:37 | sean-k-mooney | its also used to sotre instance that cannot be schduled ot "real" "comptue" cells | |
| 13:00:51 | sean-k-mooney | jkulik: ya no you put those in cell 0 | |
| 13:01:02 | jkulik | thank you. helped a lot | |
| 13:01:26 | sean-k-mooney | right os the api need a plce to stre the full instnace object for an instance that failed to go to a real cell so we just use that for the service records as well | |
| 13:01:53 | jkulik | yeah. makes sense. thanks again | |
| 13:02:46 | sean-k-mooney | i dont think it woudl breake anything to have the scuder use the cell1 db isntead but it buys you nothing either because you still need cell0 and the schduelr does not work per cell so we recommend cell0 because it alwasy extis and it shoudl be under less load | |