| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-20 | |||
| 16:57:02 | bauzas | looks not | |
| 16:57:11 | bauzas | so, I hereby officially declare the meeting as over. | |
| 16:57:14 | bauzas | thanks all | |
| 16:57:18 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-20-16.00.log.html | |
| 16:57:18 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-20-16.00.txt | |
| 16:57:18 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-20-16.00.html | |
| 16:57:18 | opendevmeet | Meeting ended Tue Sep 20 16:57:18 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:57:18 | bauzas | #endmeeting | |
| 16:57:23 | elodilles | thanks bauzas o/ | |
| 16:57:24 | gibi | thank you folks | |
| 16:57:33 | gibi | I sign off for today now o/ | |
| 16:57:46 | bauzas | me too | |
| 16:57:49 | bauzas | Java time ! | |
| 16:57:53 | sean-k-mooney | bauzas: gibi im going to push the default change | |
| 16:57:58 | sean-k-mooney | shortly just an fyi | |
| 16:58:10 | sean-k-mooney | runnign test now but ye can get to it tommorw or whenever | |
| 16:58:14 | bauzas | sean-k-mooney: then, ping me once it's done | |
| 16:58:26 | sean-k-mooney | sure | |
| 16:58:34 | bauzas | sean-k-mooney: fwiw, I'll also try to reconnect with the tick-tock cadence | |
| 16:59:27 | sean-k-mooney | this is not really impacted by tick-tock cadance | |
| 16:59:55 | bauzas | sean-k-mooney: correct, that's what I was recollecting | |
| 17:00:04 | bauzas | that's only B relnotes | |
| 17:00:11 | bauzas | that need to be forward-ported to C | |
| 17:00:13 | bauzas | IIRC | |
| 17:00:38 | sean-k-mooney | am no it would be if it was a deprecation | |
| 17:00:52 | sean-k-mooney | to remove a config option we would have to deprecate in A and then could remove in B | |
| 17:01:02 | sean-k-mooney | but we cant depcreate in B and remove in C | |
| 17:01:03 | bauzas | anyway, I'll be late for listening about microservices and serverless knative :) | |
| 17:01:19 | sean-k-mooney | ack chat to you tomorrow | |
| 17:04:21 | sean-k-mooney | artom: you should read over https://bugs.launchpad.net/nova/+bug/1989357 | |
| 17:04:34 | sean-k-mooney | as a potential usecase for the fqdn work | |
| 17:05:19 | artom | sean-k-mooney, instance.hostname never changes, does it? | |
| 17:05:27 | sean-k-mooney | it can | |
| 17:05:42 | sean-k-mooney | in the micoversion that allowed you to set it in server create | |
| 17:05:51 | sean-k-mooney | we also allowed it to be update with server update | |
| 17:05:59 | sean-k-mooney | before 2.90 it cant | |
| 17:06:18 | artom | Ah | |
| 17:06:21 | johnsom | Oh, a new hostname chain. Will have to read the scrollback | |
| 17:06:46 | sean-k-mooney | johnsom: you have not missed much | |
| 17:06:55 | artom | Sounds like they're asking for https://review.opendev.org/c/openstack/neutron-specs/+/832658 to incorporate the possibility of the hostname changing | |
| 17:07:12 | artom | Ah, hold no, no | |
| 17:07:18 | artom | That's only for the domain | |
| 17:07:32 | sean-k-mooney | https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/855870/2/neutron_tempest_plugin/scenario/test_dns_integration.py | |
| 17:07:49 | sean-k-mooney | they wanted to change the server hostanme and see it refect in the ports | |
| 17:07:57 | sean-k-mooney | the current test is changein displayname | |
| 17:08:24 | artom | sean-k-mooney, it's still kinda different though | |
| 17:08:37 | sean-k-mooney | that form the bug | |
| 17:08:43 | sean-k-mooney | they are trying to make that work | |
| 17:08:49 | artom | So there's 1. (the Neutron spec) Expose port/network/subnet's dns_domain to guest via DHCP | |
| 17:09:04 | sean-k-mooney | yep | |
| 17:09:08 | artom | 2. (Nova spec) Expose FQDN (instance.hostname + network dns_domain) in metadata | |
| 17:09:15 | sean-k-mooney | yep | |
| 17:09:27 | artom | 3. If any of the dns_ fields are updated, notify Designate | |
| 17:09:38 | artom | Which... I'm not even sure how. | |
| 17:09:42 | sean-k-mooney | no 3 | |
| 17:09:51 | sean-k-mooney | is if i update the instnace.host in nova | |
| 17:10:00 | sean-k-mooney | nova should update teh dns_ field in neutron | |
| 17:10:05 | sean-k-mooney | and that should update desginate | |
| 17:10:24 | artom | Wait, does the port store the *hostname*? | |
| 17:10:28 | sean-k-mooney | yes | |
| 17:10:33 | johnsom | yep | |
| 17:10:36 | artom | Ah OK, that's easy enough then | |
| 17:10:52 | artom | Why was it out of scope for stephenfin's initial spec? | |
| 17:10:58 | sean-k-mooney | but so does the floating ip | |
| 17:11:02 | sean-k-mooney | and they want that to work too | |
| 17:11:12 | sean-k-mooney | and the port and floating ip can be differnt | |
| 17:11:27 | johnsom | Almost always will be different | |
| 17:11:41 | sean-k-mooney | typically just the domain but yes | |
| 17:11:48 | sean-k-mooney | it can be both | |
| 17:11:53 | sean-k-mooney | they are not ment to be linked | |
| 17:11:58 | johnsom | right | |
| 17:12:20 | sean-k-mooney | so in https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/855870/2/neutron_tempest_plugin/scenario/test_dns_integration.py | |
| 17:12:43 | sean-k-mooney | they were trying to assert that updatign the server name update the name of the fip | |
| 17:12:50 | sean-k-mooney | and that the old name was not found anymore | |
| 17:13:04 | sean-k-mooney | line 145 and 146 | |
| 17:13:23 | sean-k-mooney | im not conviced we shoudl do that | |
| 17:13:52 | sean-k-mooney | but i wanted to highlight this usecase so we can definitly say nova should not do this or not in the spec | |
| 17:14:31 | sean-k-mooney | i stongly feel like this is somethign you shoudl update in neutron and or desginate seperatly | |
| 17:15:02 | johnsom | IMO nova should not "know" about floating IPs in neutron. | |
| 17:16:26 | artom | IOO as well ;) | |
| 17:23:26 | opendevreview | sean mooney proposed openstack/nova master: update default overcommit https://review.opendev.org/c/openstack/nova/+/830829 | |
| 17:23:53 | sean-k-mooney | johnsom: ack there is a question of shoudl nova update the value on ports it created | |
| 17:24:07 | sean-k-mooney | i.e. where you specified --network rather then a port uuid | |
| 17:24:15 | sean-k-mooney | btu i agree on floating ips | |
| 17:25:13 | johnsom | Yeah, I think an updated hostname field in nova should push down to those ports created for it. That makes sense. Though the guest won't get updated, but that is kind of expected. | |
| 17:25:46 | sean-k-mooney | so there are 2 nova related feature propoasl that interacat with it | |
| 17:25:59 | sean-k-mooney | artom is looking at maybe updating the metadata again | |
| 17:26:16 | sean-k-mooney | and there is a user data update feature | |
| 17:26:33 | sean-k-mooney | so if artoms feature is doen the metadata api woudl be updated | |
| 17:26:59 | sean-k-mooney | wether the guest woudl actully use that i dont know | |
| 17:27:30 | johnsom | Yeah, in the current reality, a guest wouldn't pick it up until a reboot. | |
| 17:28:35 | sean-k-mooney | or later if the agent is not run on each reboot | |
| 17:29:06 | sean-k-mooney | so i would like to know why they tohght that tempest test shoudl pass today | |
| 17:30:49 | sean-k-mooney | i.e. updating vm name (hostname or dispaly name) would have any impact on neutron port or floating ips | |
| 17:32:26 | johnsom | It certainly should not impact floating IPs. I guess ports makes sense if nova created the port, but I don't think it's implemented today. | |
| 17:32:40 | sean-k-mooney | its not | |
| 17:32:48 | sean-k-mooney | nova will only ever set this once | |
| 17:32:51 | johnsom | Yeah, so sounds like an RFE | |
| 17:32:52 | sean-k-mooney | and then never touch it again | |
| 17:33:43 | sean-k-mooney | yep thats why i closed it as invlaid but even as an RFE request without more context im not really seing a usecase that would entiese me to add this to nova | |