| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-28 | |||
| 11:36:38 | sean-k-mooney[m] | tkajinam: i had a look at the castellan pathch. i have +2’d it but form my perspective you missed the non-clinet lib freeze so im treating this as an expcetion because its small but i dont think its in line wiht our normal release process | |
| 11:38:26 | sean-k-mooney[m] | bauzas: i was holding off on comeitng on the docs change because i didnt want you to repsin it but since you have im going to ask you to correct some other issues | |
| 11:56:15 | frickler | sean-k-mooney[m]: the lib was released in time last week, it is just the reqs update that got stuck because of test failures. technically there's time for that until friday without an exception | |
| 11:57:10 | sean-k-mooney[m] | frickler that not how i managed this when i was the release leasion for nova and i was asked ot get an excption in the past | |
| 11:57:23 | sean-k-mooney[m] | for libs in the same situration | |
| 11:58:36 | sean-k-mooney[m] | as i said im not blockign this but i dont really like late breakign chnages like this espcially when the lib in question could have added the new api witout breaking the existing users | |
| 11:59:23 | stblatzheim | sean-k-mooney[m]: Regarding https://review.opendev.org/c/openstack/nova/+/910466 i don't get why this should be solved in neutron. It's just a changed behaviour which wasn't adapted in the decision making of dhcp in nova-api. Can you clarify this? | |
| 11:59:33 | sean-k-mooney[m] | this should have been a castalan 5.0 bump not 4.4 by the way as its an api breakage | |
| 11:59:48 | sean-k-mooney[m] | it should not have been a minor version bump | |
| 11:59:54 | frickler | I don't want to defend that change, but I also note that the nova patch has gone unreviewed for 5 months or so | |
| 11:59:55 | sean-k-mooney[m] | because its not additive | |
| 12:01:23 | sean-k-mooney[m] | stblatzheim: this behavior should not vary based on the neutron backend | |
| 12:01:36 | sean-k-mooney[m] | if the subnet has dhcp enabled in any form | |
| 12:02:32 | sean-k-mooney[m] | the subnet should have a port with network:dhcp | |
| 12:02:34 | stblatzheim | But then the whole decision making is not valid anymore. You could just get the enable_dhcp option and not search for any port with the tenant then | |
| 12:02:44 | sean-k-mooney[m] | as the owner | |
| 12:03:24 | stblatzheim | As there are no dedicated dhcp ports anymore this descision can't be done like this in ovn context | |
| 12:04:00 | stblatzheim | Otherwise you would have to fake the device owner in neutron api | |
| 12:04:15 | frickler | sean-k-mooney[m]: is "the subnet should have a port with network:dhcp" defined in some nova-neutron contract? or is that just the way it used to work with earlier backends? | |
| 12:04:49 | sean-k-mooney[m] | no what im saying is neutron is not implementing the api correctly the ovn dhcp interface should be network:dhcp_port as the owner | |
| 12:05:07 | frickler | but iiuc there is no specific interface for dhcp | |
| 12:05:29 | sean-k-mooney[m] | frickler: that is the way its used in other backend so we should not be special casing for ovn | |
| 12:05:39 | sean-k-mooney[m] | and if we are then thats reallly a feature not a bug | |
| 12:06:04 | frickler | sean-k-mooney[m]: maybe nova relying on undocumented things is the bug | |
| 12:06:22 | sean-k-mooney[m] | the implict contract is that the ip used for dhcp is held by a port with network:dhcp | |
| 12:06:54 | sean-k-mooney[m] | or ovn doing it differntly is a bug | |
| 12:08:32 | sean-k-mooney[m] | i dont like adding yet another fallback here | |
| 12:09:02 | sean-k-mooney[m] | like if a diffent backend decided to use somethign difffent again we should not have to keep extiding nova for this | |
| 12:09:07 | stblatzheim | The fallback to the gateway ip seems worse for me | |
| 12:09:51 | stblatzheim | Why do we even need an ip in dhcp context? | |
| 12:11:11 | sean-k-mooney[m] | well what is broekn for you now when dhcp is not in the metadata | |
| 12:11:54 | stblatzheim | The instance get's a static configuration for the network interfaces instead of a dhcp configuration | |
| 12:12:10 | sean-k-mooney[m] | oh you dont want static ips | |
| 12:13:03 | stblatzheim | Thats why we use dhcp :) In the specific case we have vms that may get additional routes via dhcp | |
| 12:13:32 | sean-k-mooney[m] | i would be ok with a nova change to the metadata to make this work based on if dhcpu is enabled and not based on finding a port ip for that server | |
| 12:14:45 | sean-k-mooney[m] | like i think we should just be using subnet.get(‘enable_dhcp’) to set the type in the metadata to ipv4_dhcp | |
| 12:15:06 | stblatzheim | Would be fine for me, do we even need a real ip in the dhcp_server field subnet_dict['dhcp_server']? | |
| 12:15:47 | sean-k-mooney[m] | likely not but i am not sure you should be fixing this in _get_subnets_from_port | |
| 12:16:08 | sean-k-mooney[m] | if you are trying to fix this for metadata i think a fix in the generatio would make more sense | |
| 12:17:02 | stblatzheim | Let me just check. My first work on openstack code itself ... | |
| 12:23:06 | sean-k-mooney[m] | https://github.com/openstack/nova/blob/7fa1859576ac577da89cb817f93b1c54d3a937ce/nova/virt/netutils.py#L168 | |
| 12:23:21 | sean-k-mooney[m] | my inclination is it should be adressed in ^ or related code | |
| 12:23:39 | sean-k-mooney[m] | in either case we will need at least unit test coverage for this | |
| 12:28:10 | sean-k-mooney[m] | stblatzheim: you should be fixing this here https://github.com/openstack/nova/blob/7fa1859576ac577da89cb817f93b1c54d3a937ce/nova/virt/netutils.py#L292 | |
| 12:29:03 | stblatzheim | I'll check if i find a suitable solution there. | |
| 12:30:06 | sean-k-mooney[m] | you might be able to just check subnet.get_meta(enable_dhcp) | |
| 12:31:16 | stblatzheim | I think there would be an additional change to make enable_dhcp available there | |
| 12:31:33 | stblatzheim | But i'm sure i can make this | |
| 12:34:54 | stblatzheim | subnet_dict (which is returned) is defined here: https://github.com/openstack/nova/blob/7fa1859576ac577da89cb817f93b1c54d3a937ce/nova/network/neutron.py#L3608 Would need to add the enable_dhcp conditionaly here also i suppose. Should i make a new review for this? | |
| 12:35:03 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Auto set heartbeat_in_pthread for wsgi services https://review.opendev.org/c/openstack/nova/+/909880 | |
| 13:02:12 | sean-k-mooney | stblatzheim adding the enable_dhcp there is fine | |
| 13:02:33 | sean-k-mooney | stblatzheim: so yes feel free to update your exixting reivew | |
| 13:03:09 | sean-k-mooney | so just add enable_dhcp there adn then make the if check for either enable_dhcp or dhcp_server | |
| 13:05:38 | opendevreview | ribaudr proposed openstack/nova master: Check shares support (compute manager) https://review.opendev.org/c/openstack/nova/+/885751 | |
| 13:05:38 | opendevreview | ribaudr proposed openstack/nova master: Allow to mount manila share using Cephfs protocol https://review.opendev.org/c/openstack/nova/+/883862 | |
| 13:05:39 | opendevreview | ribaudr proposed openstack/nova master: Check shares support (only API exception) https://review.opendev.org/c/openstack/nova/+/885752 | |
| 13:05:39 | opendevreview | ribaudr proposed openstack/nova master: Add share lock/unlock and restrict visibility https://review.opendev.org/c/openstack/nova/+/890340 | |
| 13:05:40 | opendevreview | ribaudr proposed openstack/nova master: Check shares support (API) https://review.opendev.org/c/openstack/nova/+/850499 | |
| 13:05:40 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (API) https://review.opendev.org/c/openstack/nova/+/836830 | |
| 13:05:41 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | |
| 13:05:41 | opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/885753 | |
| 13:05:42 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | |
| 13:05:43 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach_error notification https://review.opendev.org/c/openstack/nova/+/860282 | |
| 13:05:43 | opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | |
| 13:05:45 | opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | |
| 13:05:45 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach_error notification https://review.opendev.org/c/openstack/nova/+/860283 | |
| 13:05:47 | opendevreview | ribaudr proposed openstack/nova master: Docs about Manila shares API usage https://review.opendev.org/c/openstack/nova/+/871642 | |
| 13:05:47 | opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | |
| 13:12:41 | auniyal | hi melwitt, dansmith any ideas on this fail no test really failed but job failed with TIMEOUT - https://zuul.opendev.org/t/openstack/build/0e88ede030024fcbb16405750614fb2f | |
| 13:14:52 | auniyal | do you think its a deployment issue ? | |
| 13:14:53 | opendevreview | Steven Blatzheim proposed openstack/nova master: Fix nova-metadata-api for ovn dhcp native networks https://review.opendev.org/c/openstack/nova/+/910466 | |
| 13:20:54 | opendevreview | Steven Blatzheim proposed openstack/nova master: Fix nova-metadata-api for ovn dhcp native networks https://review.opendev.org/c/openstack/nova/+/910466 | |
| 13:22:29 | stblatzheim | sean-k-mooney: Updated the review like you suggested and reused existing unit test with the adaption of the new behaviour. | |
| 13:31:54 | sean-k-mooney | stblatzheim: ack im in a meeting but ill take a look when done. | |
| 13:39:52 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Auto set heartbeat_in_pthread for wsgi services https://review.opendev.org/c/openstack/nova/+/909880 | |
| 13:57:26 | opendevreview | Konrad Gube proposed openstack/nova master: Use Cinder's os-extend_volume_completion volume action. https://review.opendev.org/c/openstack/nova/+/873560 | |
| 14:54:20 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: add a periodic check for migrations https://review.opendev.org/c/openstack/nova/+/909598 | |
| 14:54:20 | opendevreview | Sylvain Bauza proposed openstack/nova master: Modify the mdevs in the migrate XML https://review.opendev.org/c/openstack/nova/+/904258 | |
| 14:54:27 | bauzas | sean-k-mooney: did a respin ^ was simplier | |
| 15:04:02 | tkajinam | sean-k-mooney, I totally agree there are multiple things we can improve, but for this specific case tbvh this was out of our control from oslo side (at least it was out of my own control) because castellan is maintained between barbican and oslo and all the changes were merged by barbican side without any consultation to oslo side... | |
| 15:04:27 | tkajinam | and they don't really care about anything they are not actually interested in. /me sighs | |
| 15:07:45 | tkajinam | we probably should try creating a mid-cycle release of some oslo libraries to detect such problems early, so that we can more smoothly complete requirement bumps, instead of finding multiple problems at last minutes | |
| 15:18:01 | sean-k-mooney | bauzas: thanks +2w on the non WIP patch | |
| 15:18:13 | sean-k-mooney | ill review the perodic after you decdid it ready | |
| 15:18:13 | bauzas | tks | |
| 15:18:26 | bauzas | I need to test it | |
| 15:18:34 | bauzas | not sure I'll have time until Friday | |
| 15:18:40 | bauzas | ETOOMANYTHINGS | |
| 15:19:16 | sean-k-mooney | tkajinam: or we just need to have something mroe visiable in our meetings ectra | |
| 15:19:33 | sean-k-mooney | to ensure we have better comuncitation | |
| 15:19:46 | sean-k-mooney | tkajinam: we have beenb usign a etherpad this cycle | |
| 15:19:54 | sean-k-mooney | in past cycle wee used review priority | |
| 15:20:25 | sean-k-mooney | so we just need a way to signal this work will be needed eiarlr so ti does not come as a surpise at the end. | |
| 15:23:00 | tkajinam | I'll try | |
| 15:34:49 | kgube | sean-k-mooney, bauzas: regarding yesterdays discussion of my patch, would it also be acceptable to just check for the supported cinder microversion in the code, so the patch is compatible with older cinderclient versions? | |
| 15:35:41 | dansmith | sean-k-mooney: so I'm a bit confused about how this encryption stuff works with ceph | |
| 15:36:29 | dansmith | sean-k-mooney: the key we're using to access a given disk is known really only to libvirt and qemu on the host, right? It's really qemu's integrated rbd client that's doing the luks on top, AFAK | |
| 15:36:56 | dansmith | so what I don't understand is how something that does *not* know about those things do image operations like flatten when it doesn't know those details | |
| 15:37:30 | dansmith | like, let's say we have an unencrypted base image, encrypted root disk on top. we haven't read or written block 10, | |
| 15:38:01 | dansmith | we call librbd to flatten the image (detach from parent), we have to copy any un-CoW'd blocks into the detached disk to make it whole | |