Friday, 2025-08-29

opendevreviewTakashi Kajinami proposed openstack/placement master: Remove the job with Ubuntu 22.04  https://review.opendev.org/c/openstack/placement/+/95882001:40
opendevreviewTakashi Kajinami proposed openstack/placement master: Remove the job with Ubuntu 22.04  https://review.opendev.org/c/openstack/placement/+/95882003:02
opendevreviewTakashi Kajinami proposed openstack/nova master: Follow-up of AMD SEV-ES support  https://review.opendev.org/c/openstack/nova/+/95882203:54
opendevreviewTakashi Kajinami proposed openstack/nova master: Follow-up of AMD SEV-ES support  https://review.opendev.org/c/openstack/nova/+/95882203:59
opendevreviewMerged openstack/nova master: Ask for pre-prod testing for native threading  https://review.opendev.org/c/openstack/nova/+/95742404:35
opendevreviewTakashi Kajinami proposed openstack/nova master: Follow-up of AMD SEV-ES support  https://review.opendev.org/c/openstack/nova/+/95882204:54
tkajinamI've proposed a follow-up of SEV-ES support, which addresses most of the comments https://review.opendev.org/c/openstack/nova/+/958822 . Could you please have a look when you have time ?04:55
tkajinambauzas, sean-k-mooney ^^^04:55
opendevreviewMerged openstack/nova master: Allow to start unit test without eventlet  https://review.opendev.org/c/openstack/nova/+/95343604:57
opendevreviewMerged openstack/placement master: Remove Python 3.9 support  https://review.opendev.org/c/openstack/placement/+/95336705:13
bauzastkajinam: sure, will look07:20
opendevreviewRajesh Tailor proposed openstack/nova stable/2025.1: Fix 'nova-manage image_property set' command  https://review.opendev.org/c/openstack/nova/+/95883407:40
opendevreviewTobias Urdin proposed openstack/nova master: api-ref: Add new lines not allowed for server description  https://review.opendev.org/c/openstack/nova/+/92875808:01
opendevreviewTobias Urdin proposed openstack/nova master: libvirt: update description for live_migration_completion_timeout  https://review.opendev.org/c/openstack/nova/+/87408308:02
opendevreviewTobias Urdin proposed openstack/nova master: libvirt: set remaining to 0 when no disk to migrate  https://review.opendev.org/c/openstack/nova/+/87384608:03
opendevreviewTobias Urdin proposed openstack/nova master: Remove libvirt tunnelled migration  https://review.opendev.org/c/openstack/nova/+/87902108:05
opendevreviewTobias Urdin proposed openstack/nova master: Remove libvirt tunnelled migration  https://review.opendev.org/c/openstack/nova/+/87902108:06
opendevreviewTobias Urdin proposed openstack/nova master: Retry more volume API functions on server error  https://review.opendev.org/c/openstack/nova/+/94298108:08
opendevreviewTobias Urdin proposed openstack/nova master: Remove gabbi from test-requirements.txt  https://review.opendev.org/c/openstack/nova/+/95357808:10
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for volumes APIs  https://review.opendev.org/c/openstack/nova/+/95234809:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for snapshots APIs  https://review.opendev.org/c/openstack/nova/+/95234909:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for volume attachments APIs  https://review.opendev.org/c/openstack/nova/+/95235009:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for floating IP APIs  https://review.opendev.org/c/openstack/nova/+/95297209:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for security group APIs  https://review.opendev.org/c/openstack/nova/+/95297309:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for services APIs  https://review.opendev.org/c/openstack/nova/+/95319609:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for server usage audit log APIs  https://review.opendev.org/c/openstack/nova/+/95320909:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for tenant network APIs  https://review.opendev.org/c/openstack/nova/+/95608809:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for simple tenant usage APIs  https://review.opendev.org/c/openstack/nova/+/95609609:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for limits API  https://review.opendev.org/c/openstack/nova/+/95613909:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for quota class sets API  https://review.opendev.org/c/openstack/nova/+/95614009:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for quota sets API  https://review.opendev.org/c/openstack/nova/+/95614109:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for migrations API  https://review.opendev.org/c/openstack/nova/+/95614209:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for server migrations API  https://review.opendev.org/c/openstack/nova/+/95614309:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for server tags API  https://review.opendev.org/c/openstack/nova/+/95614409:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for server metadata APIs  https://review.opendev.org/c/openstack/nova/+/95614509:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Simplify servers views (1/3)  https://review.opendev.org/c/openstack/nova/+/95623109:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Simplify servers views (2/3)  https://review.opendev.org/c/openstack/nova/+/95623209:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Simplify servers views (3/3)  https://review.opendev.org/c/openstack/nova/+/95623309:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for servers APIs (1/6)  https://review.opendev.org/c/openstack/nova/+/95623409:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for servers APIs (2/6)  https://review.opendev.org/c/openstack/nova/+/95623609:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for servers APIs (3/6)  https://review.opendev.org/c/openstack/nova/+/95623709:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for servers APIs (4/6)  https://review.opendev.org/c/openstack/nova/+/95623809:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for servers APIs (5/6)  https://review.opendev.org/c/openstack/nova/+/95623909:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for servers APIs (6/6)  https://review.opendev.org/c/openstack/nova/+/95624009:17
opendevreviewStephen Finucane proposed openstack/nova master: api: Add response body schemas for server shares APIs  https://review.opendev.org/c/openstack/nova/+/95626609:17
opendevreviewStephen Finucane proposed openstack/nova master: tests: Invert validation check  https://review.opendev.org/c/openstack/nova/+/95624109:17
opendevreviewMerged openstack/placement master: Reproduce bug 2104040: allocate in over-capacity  https://review.opendev.org/c/openstack/placement/+/94546410:04
tkajinamo/ anyone has a min to review https://review.opendev.org/c/openstack/placement/+/958820 to remove remaining Jammy job ?10:06
gibitkajinam: +2 bauzas ^^ easy win10:08
bauzasyup10:08
bauzastkajinam: you deserve some rest, you know10:09
tkajinambauzas, gibi thanks !10:09
tkajinamI eventually took PTO today so had a good rest during the day :-)10:10
bauzaswell, you actually worked two days in a day yesterday so indeed, take PTO :)10:11
* bauzas when I saw tkajinam's ping in my already unreasonable time : wow.10:11
opendevreviewMerged openstack/placement master: Fix placement allocate while over-capacity  https://review.opendev.org/c/openstack/placement/+/94546510:45
gibidansmith: ^^ \o/10:51
stephenfingmaan: gibi: bauzas: As sean-k-mooney said I've been out sick with a bug the last two days. Sorry for pushing that series so late: (a) I didn't realise FF was yesterday (I thought I'd another week) and (b) I couldn't push earlier as there would have been horrific conflicts with the (much larger) OpenAPI series. I'm happy to wait until early in G to get that in and appreciate the reviews10:59
stephenfinI'm getting both it and the OpenAPI series tidied up so that we can hopefully get them in asap once we branch10:59
gibistephenfin: hope you are feeling better now. Thanks for working on these improvements11:01
stephenfinnw11:03
gibisean-k-mooney: how do you feel about https://review.opendev.org/c/openstack/nova/+/936093 ? I think we saw the issue now downstream as well (see slack). I reviewed the patch and I think this is a good small fix.11:34
sean-k-mooneygibi: ill need to load context as it looks liek i have not reviewd it befreo11:35
sean-k-mooneywe do kwno that there is a bug in mtu chagne on live migration but we need to ensure that it never changes across the migrtion11:36
gibitldr: mtu is not in our network cache and that can cause live migration issue later as libvirt don't allow MTU change during live migration but we wrongly used the nil from the cache11:36
sean-k-mooneyright 11:36
sean-k-mooneyso ill readd the patch but how we palnned to fix that was to make sure we dont modify the xml by saving the orginal mtu if its present11:36
sean-k-mooneywe also do not incldue the mtu intetionally in teh netork metadlata if the neutron network has dhcp enabled11:37
gibiOK. So this is more complicated than I anticipated11:37
sean-k-mooneyso we need to be careful not to change that11:37
sean-k-mooneygibi: so the issue sometime come up with people going form ml2/ovs to ml2/ovn11:38
sean-k-mooneynova does nto actully supprot changing the mtu on a network11:38
sean-k-mooneythere was an optional extention to allow that in neturon11:38
sean-k-mooneybtu it was never supproted on the nova side11:39
sean-k-mooneyso the mtu should never change on a live migration 11:39
sean-k-mooneyhowver when you do the db hacks to migrate form ml2/ovs to ml2/ovn you cahnge from vxlan to geneve and that reduces the mtu11:39
gibiin this case the source mtu is undefined, that converted to 0 and then of course that does not match the dest mtu that is set11:40
sean-k-mooneywell the is an other rinkel11:41
sean-k-mooneythere are 2 formats for virtio feature flags11:41
sean-k-mooney32bit and 64bit11:41
sean-k-mooneyif you spcify the mtu in the xml it changes form 32bit to 64bit11:41
sean-k-mooneywhich is also nto supproted by qemu during a live migration11:41
sean-k-mooneyso if the xml does nto have an mtu we cant add it durign a live migration11:42
gibiI see, so this is the case ^^11:42
gibinova tries to add it11:42
sean-k-mooneythat why we orginally started down the line of grab the mtu form the port and store it then generate the new config and restore the mtu11:43
sean-k-mooneygibi: yep so we fixed this once before after i acindeltely broke vexhost11:43
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova/+/55307211:45
sean-k-mooneythat was the change to set the mtu in the first palace (its also neede for jumbo frames)11:45
sean-k-mooneyhttps://bugs.launchpad.net/nova/+bug/174749611:46
sean-k-mooneythat shoudl result in ports being attached with an mtu as well11:47
sean-k-mooneygibi: the issue they are reproting in https://bugs.launchpad.net/nova/+bug/208053111:47
opendevreviewMerged openstack/placement master: Remove the job with Ubuntu 22.04  https://review.opendev.org/c/openstack/placement/+/95882011:47
sean-k-mooneyi think artom had satred to fxi a while ago11:47
sean-k-mooneylet me see if i can find that11:47
opendevreviewStephen Finucane proposed openstack/nova master: db: Move regex helpers to utils  https://review.opendev.org/c/openstack/nova/+/95874511:48
opendevreviewStephen Finucane proposed openstack/nova master: tests: Clean up flavors tests  https://review.opendev.org/c/openstack/nova/+/95874611:48
opendevreviewStephen Finucane proposed openstack/nova master: api: Simplify API version check for flavor description  https://review.opendev.org/c/openstack/nova/+/95874711:48
opendevreviewStephen Finucane proposed openstack/nova master: api: Add ability to filter flavors by name  https://review.opendev.org/c/openstack/nova/+/95874811:48
opendevreviewStephen Finucane proposed openstack/nova master: api: Remove dead fields from flavors response  https://review.opendev.org/c/openstack/nova/+/95874911:48
opendevreviewStephen Finucane proposed openstack/nova master: api: Restrict additional query string arguments  https://review.opendev.org/c/openstack/nova/+/95875011:48
opendevreviewStephen Finucane proposed openstack/nova master: tests: Fix typo  https://review.opendev.org/c/openstack/nova/+/95885511:48
opendevreviewStephen Finucane proposed openstack/nova master: api: Add runtime check for query additionalProperties  https://review.opendev.org/c/openstack/nova/+/95885611:48
opendevreviewStephen Finucane proposed openstack/nova master: tests: Add missing test coverage  https://review.opendev.org/c/openstack/nova/+/95885711:48
opendevreviewStephen Finucane proposed openstack/nova master: WIP: api: Add runtime check for general additionalProperties  https://review.opendev.org/c/openstack/nova/+/95885811:48
sean-k-mooneygibi: https://review.opendev.org/c/openstack/nova/+/791553/111:48
sean-k-mooneyso we have a regression test https://review.opendev.org/c/openstack/nova/+/791235/311:49
sean-k-mooneythen then the poc to fix it 11:49
sean-k-mooneyand there as a seocnd attept to fix it in https://review.opendev.org/c/openstack/nova/+/852367/111:49
sean-k-mooneygibi: these all kind of stalled out partly because of review banwith11:50
gibiI'm not sure if simply checking the MTU does not change will help if we don't even have the MTU on the source host to begin with. So probably multiple fixes are needed. Anyhow I will let the downstream reported file a bug on us to get motivation to fix it11:51
gibis/reported/reporter/11:52
sean-k-mooneyack11:52
sean-k-mooneyya so there are a few issues11:52
sean-k-mooneyi might actilly have an old pathc for the mtu not being set11:52
sean-k-mooneyi think the best way forward is 1 letg create some functional repoduces for the diffent senairos 2 then fix the mtu setting on attach and then on migrate as followups11:54
gibiyepp I agree11:55
sean-k-mooneythe patch you linked migth fix part of it i woudl jsut need to trace throught he code to see why11:55
sean-k-mooneyits not obvious that it should11:56
sean-k-mooneyby the way we also knwo that there is a bug related to this that applie to sriov port as well11:58
sean-k-mooneybasiclly wehn testing seriov live mgirtion i belvie we have to use 2 sriov prot (one mac vtap and one direct) to make it work instaed of ovs and macvtapo11:59
sean-k-mooneyi dont exactly recall the details but it has somethign to do with the mtu i think as well but we could check with james parker and they might have a link12:00
sean-k-mooneywe had ot work aroudn it in our ci12:00
gibiuuu a workarond in CI sounds interesting12:02
gibithe new report upstream involves SRIOV ports12:03
gibiI guess12:03
sean-k-mooneyoh so ya12:03
sean-k-mooneyam if you have an ovs prot and a sriov prot in direct mode12:03
sean-k-mooneylive migration does not work because of somethign ot do with the mtu it hkn12:04
sean-k-mooneyi debuged it once but again dint have tiem to go fix it12:04
sean-k-mooneyok reading the bug again ya this is the same issue we see in ci12:06
sean-k-mooneybut the netwrok data in the metadata api is not alwasy the same as in the network info cache12:07
sean-k-mooneyill try and look at this review again properly next week12:08
sean-k-mooneythis is the first item i have seen that bug or patch12:09
gibiOK. thanks12:11
sean-k-mooneyim partly nerd snips because i was going to start on sumething new but you pinged me before i start on it12:13
opendevreviewStephen Finucane proposed openstack/nova master: api: Correct version for rebuild response  https://review.opendev.org/c/openstack/nova/+/95886212:14
opendevreviewStephen Finucane proposed openstack/nova master: api: Remove unnecessary action method prefix  https://review.opendev.org/c/openstack/nova/+/95886312:14
opendevreviewStephen Finucane proposed openstack/nova master: api: Deprecate os-volumes_boot API  https://review.opendev.org/c/openstack/nova/+/95886412:14
opendevreviewStephen Finucane proposed openstack/nova-specs master: Repropose remove-os-volumes_boot-api  https://review.opendev.org/c/openstack/nova-specs/+/95886512:14
gibisean-k-mooney: sorry for that. This is not urgent so feel free to punt it for a while12:14
opendevreviewStephen Finucane proposed openstack/nova-specs master: Repropose flavor-search-by-name spec  https://review.opendev.org/c/openstack/nova-specs/+/95886612:15
sean-k-mooneyim not complaining but im going to spend 15 mins considerign the patch then move on. ill come back to it on monday12:16
sean-k-mooneyi think the change they are propsoing is safe to proceed with12:17
sean-k-mooneyi am not conviced it will fix all 2-3 of the related cases i am vagely aware of but i dont think it will make any of those harder to fix later12:18
opendevreviewMerged openstack/nova-specs master: Create specs directory for 2026.1 Gazpacho  https://review.opendev.org/c/openstack/nova-specs/+/95616612:19
opendevreviewTakashi Kajinami proposed openstack/nova master: libvirt: Disable VMCoreInfo device for SEV-encrypted instances  https://review.opendev.org/c/openstack/nova/+/95886812:19
sean-k-mooneygibi: i feel like it need a bit more testing but im tempeted to pull this into one of my devstacks and try it and maybe jsut take a good enough is better then perfect approch in this case12:20
sean-k-mooneygibi: in other words we can proably proceed with this before rc1 but i want to poke at it a bit before then12:21
opendevreviewStephen Finucane proposed openstack/nova-specs master: Repropose openapi spec for Gazpacho  https://review.opendev.org/c/openstack/nova-specs/+/95886912:22
gibisean-k-mooney: OK. Thanks12:33
stephenfingmaan: For next cycle, but you'll probably like https://review.opendev.org/c/openstack/nova/+/958856/ and https://review.opendev.org/c/openstack/nova/+/958858/12:35
stephenfinone less thing for you to worry about during reviews 😄12:35
sean-k-mooneygibi: i basiclly want to see if i can replciate this with 2 ovs network with differnt mtu or if it actully need ovs + sriov to see if we can maybe test this in tempest and if it obviously fixes the issue for me locally12:37
sean-k-mooneygibi: i dont curertnly have sriov hardware avaibel to thise this simiply so i need to create 2 devstack vms using igb and set it up for live migration ectra12:39
sean-k-mooneyso i wont get to thtat today12:39
opendevreviewTakashi Kajinami proposed openstack/nova stable/2025.1: libvirt: Disable VMCoreInfo device for SEV-encrypted instances  https://review.opendev.org/c/openstack/nova/+/95887412:39
gibisean-k-mooney: sync with Arnau from neutron they migh have envs as this was reported from running neutron's whitebox against antelope12:44
sean-k-mooneyack i mostly want to see if we can test this edge case in the 1st party ci going forward via tempest without the sriov depency described in the bug13:03
sean-k-mooneyif it can happen anytime you have a vm with 2 networks with diffent mtus for exampel we can easilly add a senario test in neutron to do that13:04
sean-k-mooneylike in theory if usign the neutron whitebox tempest plugin found it downstream that same test should have repodcuded it on master right13:05
gibiyepp that theory make sense13:08
gibithere was also recent changes in that repo about the exact same test case so it might pass on master but not on older whitebox versions13:09
dansmithgibi: woohoo, thanks13:42
amorinhey team, the call to attach a volume on nova is done through rpc. During this, the wsgi worker keep the connection open (it's a synchronous call). Do you know why it's a sync call and not an async one?13:43
amorinsee here https://opendev.org/openstack/nova/src/commit/07ab08aa69ae39644c276a0907759175f8936239/nova/compute/api.py#L512713:43
amorinand there https://opendev.org/openstack/nova/src/commit/07ab08aa69ae39644c276a0907759175f8936239/nova/compute/api.py#L515013:43
dansmithamorin: probably so that we delete the BDM if the attach fails13:45
amorinhum, damn13:47
amorinwhat if we send the attach action to the compute, answer to the API request, and then delegate all the hard work to conductor / compute?13:49
dansmithI mean, anything is possible, but this used to be a situation where you got the device name back when you attached, which is not possible otherwise13:54
dansmithwhy are you asking? I'm guessing you've got attach requests stacked up or something?13:54
amorinexactly :)13:54
amorinexhausting my apache2 workers13:54
amorinand finally nova was answering 50313:55
amorindue to the fact that one of my ceph cluster was not healthy13:55
amorinI am trying to figure out a way to avoid such behavior13:55
dansmithin that case the attach is going to fail regardless right?13:56
dansmithis the problem that compute gets totally hung on ceph, or that it waits too long for ceph?13:56
amorinyes, it fails after the RPC timeout13:57
dansmithbecause part of the eventlet stuff is hopefully going to make us less stupid about talking to (and specifically timing out on) ceph in the compute node13:57
dansmithso having a short recoverable timeout there would help your situation I think, yeah?13:57
amorinI think so13:58
amorinsomething under 10s13:59
amorinat least that would help13:59
dansmithgibi: are you seeing this? ^14:00
amorinotherwize, I was thinking to have dedicated apache workers for attach volume requests, so at least 503 answers are given only to people trying to attach, but other calls succeed, do you know if some other operators are already doing this?14:01
dansmithamorin: speaking of that in general, are you positioned to provide some pre-prod feedback for us on 2025.2 with scheduler and api in non-eventlet mode? we really need some real-world testing of those as we work on the other services14:01
gibidansmith: not hanging on ceph for ever, sure. :)14:02
dansmithamorin: no, I'm not sure, but that's definitely something I'd consider yeah14:02
dansmithgibi: :P14:02
amorindansmith: about preprod, maybe I can talk to the team about this14:03
dansmithamorin: that would be super helpful (hopefully for both of us :) )14:04
gibiamorin: if you hit some walls with non-eventlet services then feel free to ping me as well with the issue I was the one that commites most of the crimes there 14:06
dansmithamorin: unless everything goes well, in which case it was a team effort :D14:07
jkulikattachments and synchronous calls reminds me of the bug report: https://bugs.launchpad.net/nova/+bug/193040614:08
amorinack gibi 14:08
gibidansmith: btw, just verified that with the futurist fix https://review.opendev.org/c/openstack/futurist/+/958689 aggregate image caching works well in threding mode now. The futurist fix will not be in Flamingo due to req freeze, but at least we can land nova-conductor change early in G14:08
dansmithgibi: excellent14:08
gibidansmith: yepp yepp, failure is on my, success is on the team :)14:08
gibis/on my/on me/14:09
amorinjkulik: sounds like my exact issue14:09
dansmithjkulik: yep14:09
jkulikmaybe we can get that mentioned spec back on track? :D14:09
jkuliksince eventlet will go away, we also need a solution for this problem. currently, we're still on the eventlet-based webserver for only this reason :/14:11
dansmithwe could just make this an async operation in a later microversion14:11
amorin+114:11
dansmitheasiest would be to delegate to conductor and keep compute the same14:11
dansmiththat's the least upgrade-impact too14:11
jkulik> simply an approximation by most virt drivers as their underlying hypervisors cannot guarantee how the device will eventually be presented.14:12
jkulikmy understanding was, that we cannot guarantee the device name anyways14:12
dansmithbut it might require blocking earlier microversions to prevent people from triggering it14:12
jkulikso the whole call is ... senseless14:12
dansmithjkulik: on libvirt it's fairly pointless, but it was not on other hypervisors14:12
jkulikI can say it's also pointless on vmware14:12
dansmithgibi: so maybe we should make this under the eventlet removal umbrella.. moving this to an async task on conductor14:15
jkulikhttps://github.com/sapcc/nova/commit/e4e8e6276ab0324704f31d6a3cc4e47f061d25ca this is how we currently try to get relieve on the wait time for the lock, FYI14:15
dansmiththe spec (as skimmed) looks far more complex than it needs to be if we just kick this to conductor in a newer microversion14:15
gibidansmith: maybe. I'm a bit affraid of increasing the scope. But I understand that it is related14:15
dansmithwell, if jkulik is sticking on eventlet because of this that tells me that (a) people might be less likely to try threaded until they're forced and (b) a lot more people will hit this once they move14:16
dansmithand tbh, it's probably worth a security hardening classification since this is sort of DoSable14:16
jkulikI agree to ^14:17
jkulikDoS waiting to happen14:17
dansmithsince it's friday maybe I'll at least write this up in a spec rough draft to capture it while it is in my head14:19
jkulikplease CC me on that. I'm quite interested in the topic :)14:19
amorinCC me as well :)14:20
dansmithare either of you interested in working on the implementation?14:20
jkulikyes, I can probably do that14:21
amorinnot sure I would have a lot of time very soon, but we I probably help (or someone from our team)14:22
dansmithcool14:23
amorinbut I try to motivate our management, as this is affecting us quite badly14:23
gibiI can be pulled in as reviewer for sure. If we decide that this should be fixed before the n-cpu gets threading support then I can be pulled in as author as well14:23
gibidansmith: thank for writing up a spec skeleton. My friday brain is already pretty useless anyhow14:24
dansmithI don't think this is going to be very big and I don't think it needs to be serialized against n-cpu work14:25
gibiI just try to limit the number of things open in parallel waiting for me 14:26
dansmithack14:26
opendevreviewDan Smith proposed openstack/nova-specs master: WIP: Spec for async volume attach  https://review.opendev.org/c/openstack/nova-specs/+/95890015:10
dansmithjkulik: amorin ^ .. just rough brain dump of what we talked about15:10
amorinyay!15:11
ratailorsean-k-mooney, gibi could you please review this https://review.opendev.org/q/Ifc20894801f723627726e3c9bed7076144542660 and provide your suggestion on approach here https://review.opendev.org/c/openstack/nova/+/95446015:11
dansmithI'm sure I saw the bug years ago when it was filed, but this is the sort of latent thing I don't want to lose track of as we push for eventlet deprecation,15:12
dansmithwhere we think "yeah everything works in devstack" but we have lots of smaller reasons like this that prevent people from actually being able to move15:13
dansmiththis isn't even the class of things that are highest concern (i.e. general threading problems, deadlocks, etc) but they are just as much of a problem for getting people transitioned15:13
ratailorstephenfin, submitted fix for microversion v2.100 as well https://review.opendev.org/c/openstack/python-openstackclient/+/958829 and backported v2.96 to relevant stable/releases https://review.opendev.org/q/I1e398bb3379fa6443b0a44db76baaf6241a945e715:19
gmaanstephenfin: perfect, that is really helpful. thanks. ack about targeting for next cycle15:43
gmaansean-k-mooney: glancer service role fix is ready for review now https://review.opendev.org/q/topic:%22glance-service-api%2219:23
*** gmaan is now known as gmaan_afk19:30
opendevreviewMerged openstack/nova master: api: Correct expected errors  https://review.opendev.org/c/openstack/nova/+/95164021:12
*** gmaan_afk is now known as gmaan23:20

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!