Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-05-19
09:50:49 opendevreview Balazs Gibizer proposed openstack/nova master: DNM:Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450
09:52:25 Uggla bauzas, sean-k-mooney if you have 5mn can tou please review 949711: Mention IRC topic update in PTL post-PTG checklist | https://review.opendev.org/c/openstack/nova/+/949711
09:55:19 sean-k-mooney Uggla: sure im aboot to kick off a vm os install so ill finsih that and then take a look
09:56:22 Uggla sean-k-mooney, thx no hurries at all.
09:56:39 Uggla This is more to not forget about it.
10:02:15 sean-k-mooney i raced with gibi
10:02:18 sean-k-mooney its on its way now
10:20:51 opendevreview Merged openstack/nova master: Mention IRC topic update in PTL post-PTG checklist https://review.opendev.org/c/openstack/nova/+/949711
10:36:00 gibi :)
10:46:59 opendevreview Balazs Gibizer proposed openstack/nova master: WIP: allow service to start with threading https://review.opendev.org/c/openstack/nova/+/948311
10:46:59 opendevreview Balazs Gibizer proposed openstack/nova master: Document threading mode and tuneables https://review.opendev.org/c/openstack/nova/+/949364
10:47:00 opendevreview Balazs Gibizer proposed openstack/nova master: DNM:Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450
12:04:02 gibi sean-k-mooney: dansmith: most of the eventlet removal series is ready for review. You can ignore the last two patches for now but the rest should be good for a review round
12:04:20 gibi series starts here https://review.opendev.org/c/openstack/nova/+/947966
12:04:54 sean-k-mooney ack, whats the status fo the oslo threading backend
12:05:22 sean-k-mooney are we still waiting on an inital release with that supprot?
12:05:54 sean-k-mooney i know the inial part of the seriese is not depending on that but has there been much progress? i saw some maining list posts asking to merge it
12:08:29 gibi sean-k-mooney: yeah we waiting for the merge and release
12:09:07 gibi there is good progress on the patch and has one +2
12:09:15 gibi so it is not far behind
12:10:05 sean-k-mooney ack. i see the previous run on the first patch was green how has the ci stablity been so far
12:11:42 gibi I see now suspicious tempest test failure on the last patch in the nova-next job. So I would say we are in good shape tempestvise. I also run a munch of negative scenarios with hanging or slow DB.
12:11:54 gibi bunch of :)
12:12:01 gibi and I ran them locally obviously
12:13:21 gibi as we don't have the oslo.service release yet we will still have time to run nova-next a couple of times before we land the switchover
12:13:24 gibi in nova-next
12:14:10 gibi The test result are also looking good on the eventlet based nova-scheduler side. I don't track any suspicious failures. I rechecked failed patches with explanation pointing out existing known instabilities
12:14:27 gibi I will keep monitoring the results
12:15:24 gibi I will do one more integration check locally with the latest oslo.service patch version and then I will also +1 the patch there
12:15:49 gibi the author is responsive, he fixed couple of issue I reported and did improvements for us
12:16:18 gibi he is planning for folluw up patches based on recent non blocking comments
12:17:05 sean-k-mooney that all sounds good
12:17:31 gibi sean-k-mooney: if you want to run the unit/functional tests in the last couple of patches (after the doc patch) then you need to manually install the oslo.service patch in your venv as there we start to actively depend on the backend initialization logic
12:17:53 gibi same is true for the doc gen target as well
12:18:19 sean-k-mooney well
12:18:32 sean-k-mooney the docs is only ture if we are auto generating the config docs
12:18:46 sean-k-mooney liek it shoudl work with the old version but not render the new options right
12:19:09 sean-k-mooney or perhaps not
12:19:23 gibi the docs target imports code, the import trigger backend initialization and in the current oslo.service code mergerd we cannot call init multiple times with the same backend. In the open oslo.service patch this is imporoved.
12:19:27 sean-k-mooney it kind of depend on what code paths we are hitting
12:19:41 sean-k-mooney ah ok
12:20:15 sean-k-mooney ya so that not the first time that has casued isseus. we have the eventlet monkey patch env arg because of that too
12:20:31 sean-k-mooney i.e. we disable monkeypatching in the docs env due to the multiple imports
12:20:54 sean-k-mooney that and well we dont need to monkey patch sphinx build
12:21:07 sean-k-mooney /need/want/
12:21:12 gibi yeah it is similar
12:21:29 gibi but it will work OK as soon as the open oslo.service patch released
12:21:55 gibi as it will allow initing the backend mutliple times if we init it with the same type and it will do noop after the first init
12:23:49 sean-k-mooney if that got held up for any reason we could just wrap our call to init in the run_once decorator anyway to work around it
12:24:03 sean-k-mooney but cool none of that sounds concerning to me
12:24:59 gibi sean-k-mooney: btw, could you check https://review.opendev.org/c/openstack/devstack/+/948436 as well?
12:26:03 gibi that is the small devstack patch to make it possible to pass env variables from zuul.yaml to systemd
12:26:10 sean-k-mooney i can proably check that first :) im workign on seting up docs/reno for a new project currently so i dont have time to deep dive into the eventlet serise right away btu the devstack patch should be fine
12:27:32 sean-k-mooney gibi: i looked at that when you first pushed it so im +1 on it still
12:27:40 gibi thanks
12:28:04 sean-k-mooney gibi: since we are talking about devstack https://review.opendev.org/c/openstack/devstack/+/939825
12:28:16 sean-k-mooney do you have time to adress frickler's comment
12:28:40 sahid sean-k-mooney, bauzas o/
12:28:57 sahid anychance that you have a look into that one when you have a moement https://review.opendev.org/c/openstack/nova/+/947804
12:29:09 sahid looks reasonable and easy fix to backport
12:29:51 gibi sean-k-mooney: yepp that is on my radar to reply
12:30:25 sahid it does not basically fix the root cause but that seems reasonable, as fixing that unsync would be quite difficult I guess
12:31:26 sean-k-mooney sahid: so doing the firsterign in python is not really what we want here
12:32:06 sean-k-mooney limit is a max its nto nessiarly what you will recive
12:32:51 sahid sure but the problem here is that, during the process because we do retrieve less than the limit we do not return "next marker"
12:33:17 sahid does that make sense?
12:33:41 sahid basically the pagination is not working and we can print the other instances
12:33:56 sahid s/can/can't
12:34:16 sean-k-mooney sahid: yep i just tiraged the bug. the only part that is a bug is the lack of the marker
12:34:22 sean-k-mooney as that break paging
12:34:48 sean-k-mooney wther we shoudl be returnign 6 or 7 results is open for debate
12:35:02 sean-k-mooney but the marker being missing is defintlly wrong
12:35:13 sahid yep we are on the same page :-)
12:40:25 sahid sean-k-mooney: you indicated it as low, but this can break many apps, e.g: workflow used to compute billing
12:41:42 sean-k-mooney sahid: i indicated it as low because i was going to mark it invliad until i noticed the marker comment. the marker being missing could raise it to medium but its not high or cirtial bug by any means. it more then whichilist however
12:42:10 sahid ack thanks !
12:54:49 sean-k-mooney sahid: i left comment on the change. it does not actully show that it fixes the bug and they typs dont look correct either so it need mroe work before proceeding
12:58:44 opendevreview Stephen Finucane proposed openstack/nova-specs master: Add remove-os-volumes_boot-api spec https://review.opendev.org/c/openstack/nova-specs/+/947210
12:59:14 opendevreview Stephen Finucane proposed openstack/nova-specs master: Add remove-os-volumes_boot-api spec https://review.opendev.org/c/openstack/nova-specs/+/947210
13:00:25 opendevreview Stephen Finucane proposed openstack/nova-specs master: Add flavor-search-by-name spec https://review.opendev.org/c/openstack/nova-specs/+/940440
13:12:40 sahid sean-k-mooney: thank you for that review, hoppefuly amorin will have a look ;-)
13:13:45 opendevreview Balazs Gibizer proposed openstack/nova master: Allow services to start with threading https://review.opendev.org/c/openstack/nova/+/948311
13:13:46 opendevreview Balazs Gibizer proposed openstack/nova master: DNM:Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450
13:14:50 opendevreview Balazs Gibizer proposed openstack/nova master: Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450
13:16:17 amorin thanks for review, I will have a look
15:17:08 Uggla bauzas, your work on mtty. Does it allow to get rid of compile_mdev_samples ?
15:24:50 Uggla dansmith, I have a question about OTU. I think youd use real nvme devices for testing ? Am I right ?
15:25:16 dansmith Uggla: are you asking if I have tested it with real nvme devices?
15:30:27 Uggla dansmith, yes
15:31:02 Uggla or did you simulated them with qemu ?
15:34:00 dansmith Uggla: no, I'm using real NVMes
15:34:14 dansmith Uggla: but you can use OTU with any PCI device for testing
15:34:24 dansmith when I started I was using the vRNG
15:35:03 Uggla dansmith, I have seen this article: https://blog.christophersmart.com/2019/12/18/kvm-guests-with-emulated-ssd-and-nvme-drives/ so I wonder if this could be used to simulate them for a demo.
15:35:37 dansmith yeah idk, perhaps
15:35:53 Uggla or testing...
15:36:01 dansmith it wasn't useful to me because I wanted to be able to run the low-level cleaning routine against real hardware since that was part of what I needed to work out
15:36:14 dansmith but for just the nova plumbing, it will probably be enough
15:43:51 Uggla dansmith, thx.
15:55:42 frickler Uggla: seems we are seeing the issue you fixed for the reqs check now in designate in 2024.2 https://review.opendev.org/c/openstack/designate/+/949094 , so I fear we'll have to revert it

Earlier   Later