| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-20 | |||
| 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 | |
| 17:34:02 | sean-k-mooney | it in the nova should not do netowrking or orchstration bucket for me | |
| 17:34:32 | johnsom | Oh, now there is a statement! grin | |
| 17:34:35 | sean-k-mooney | partly because if we do we will likely get it wrong form someones perspective | |
| #openstack-nova - 2022-09-21 | |||
| 03:24:09 | melwitt | it is not intended to have to upgrade in lockstep | |
| 03:24:09 | melwitt | jkulik: at the time of that doc writing there wasn't any real world usage of the API, so it was more likely that it may need to change based on feedback from real users. glance (https://docs.openstack.org/glance/latest/admin/quotas.html) and nova are the first implementations using the API and at this point it's possible that the keystone doc could be updated to remove the "experimental" label (would have to confirm with keystone team). | |
| 09:12:07 | obre | Are the creation of blueprint something done through a git-repo (like specs) or is it simply through the web-page at https://blueprints.launchpad.net/nova ? | |
| 09:14:29 | obre | bauzas: ^ | |
| 09:15:00 | bauzas | obre: wait a sec, giving you a doc | |
| 09:15:48 | kashyap | obre: The short answer is simply through the web page :) | |
| 10:18:52 | bauzas | obre: sorry I had another urgency | |
| 10:22:56 | bauzas | obre: so, https://docs.openstack.org/nova/latest/contributor/blueprints.html | |
| 10:23:38 | bauzas | that means you need to create a blueprint but you also need to provide a change in the nova-specs repository | |
| 10:23:53 | bauzas | obre: we have a template for a spec https://specs.openstack.org/openstack/nova-specs/specs/2023.1/template.html | |
| 10:25:41 | bauzas | obre: the nova-specs project is https://github.com/openstack/nova-specs/ | |
| 10:25:57 | bauzas | as you can see, each spec is basically just a RST document | |
| 10:26:23 | bauzas | one example can be https://review.opendev.org/c/openstack/nova-specs/+/840310 | |
| 10:27:09 | bauzas | you need to add a file in specs/antelope/approved/ | |
| 10:27:31 | bauzas | if we merge the change, then it will have the spec in antelope/approved | |
| 10:27:50 | bauzas | voila, that's it | |
| 11:23:39 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix typos in nova docs https://review.opendev.org/c/openstack/nova/+/858673 | |
| #openstack-nova - 2022-09-22 | |||
| 00:38:34 | opendevreview | melanie witt proposed openstack/nova master: libvirt: stop using connection_info for NFS file format https://review.opendev.org/c/openstack/nova/+/858836 | |
| 00:38:34 | opendevreview | melanie witt proposed openstack/nova master: zuul: Add devstack-plugin-nfs-tempest-full to the check queue https://review.opendev.org/c/openstack/nova/+/781139 | |
| 06:51:56 | opendevreview | Eigil Obrestad proposed openstack/nova-specs master: Compute Inventory Customization https://review.opendev.org/c/openstack/nova-specs/+/858858 | |
| 06:52:50 | obre | bauzas: Does the following spec/blueprint make sense for you? ^ | |
| 06:53:55 | obre | Ill tried my best to follow your process, but Ill never done anythng like this before; so I would happily accept any guiding if there are things Im doing wrong. | |