| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-20 | |||
| 16:52:11 | obre | Ill sorta understand why we need the formal process; Its just that I would have preffered an easier solution for _my_ problems :P | |
| 16:52:11 | bauzas | basically, the idea is just to identify all potential design concerns (upgrades or others) before they come up at review time | |
| 16:52:18 | obre | But its fine :P | |
| 16:52:32 | gibi | :) | |
| 16:52:34 | bauzas | obre: you're litterally at the very beginning of the cycle :) | |
| 16:52:45 | bauzas | so, you wouldn't hear 'sorry, too late' | |
| 16:53:08 | bauzas | the point is, you have gibi and me for helping you out | |
| 16:53:14 | obre | \o/ | |
| 16:53:16 | sean-k-mooney | obre: one thing to think about is do you want this to be config driven. api driven or both | |
| 16:53:25 | sean-k-mooney | we will need to document tha tin the spec | |
| 16:53:29 | bauzas | sean-k-mooney: I tought we said config-driven | |
| 16:53:33 | bauzas | as provider.yaml | |
| 16:53:46 | sean-k-mooney | yes but provide.yaml can say -1 | |
| 16:53:51 | sean-k-mooney | which means this is api contoled | |
| 16:53:57 | sean-k-mooney | or something like that if we care about that usecase | |
| 16:54:02 | bauzas | making it api-driven means we accept our inventories to be changed thru osc-placement | |
| 16:54:09 | sean-k-mooney | so im assuming config driven is enough | |
| 16:54:12 | obre | I think it makes sense to be as close to the way we do CUSTOM_* today as possible? | |
| 16:54:16 | sean-k-mooney | and if so the that simple | |
| 16:54:27 | bauzas | stick to the bare minimum requirements :) | |
| 16:54:45 | bauzas | people could come up with api-driven needs later if they want to :) | |
| 16:54:54 | sean-k-mooney | ok just that was going to be one of the question si would ask in the spec review | |
| 16:55:01 | sean-k-mooney | so i didnt want it to come out of the blue | |
| 16:55:16 | bauzas | sean-k-mooney good point, stating that api-driven is out of the spec seems reasonable | |
| 16:55:39 | sean-k-mooney | yep we can state is as not a usecase we want to enabel now in the alternitives | |
| 16:55:46 | bauzas | anyway, we're approaching end of time and we have a way forward | |
| 16:55:50 | sean-k-mooney | obre: anyway as bauzas said keep it simple for now | |
| 16:55:57 | obre | sean-k-mooney: Ack. | |
| 16:56:11 | bauzas | anything to else to bring before we call it out ? | |
| 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 | |