Earlier  
Posted Nick Remark
#openstack-nova - 2022-09-20
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
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 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).
03:24:09 melwitt it is not intended to have to upgrade in lockstep
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

Earlier   Later