| opendevreview | melanie witt proposed openstack/nova master: libvirt: Use common naming convention for ephemeral disk labels https://review.opendev.org/c/openstack/nova/+/947541 | 09:27 |
|---|---|---|
| opendevreview | Balazs Gibizer proposed openstack/nova master: Translate scatter-gather to futurist https://review.opendev.org/c/openstack/nova/+/947966 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Use futurist for _get_default_green_pool() https://review.opendev.org/c/openstack/nova/+/948072 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Replace utils.spawn_n with spawn https://review.opendev.org/c/openstack/nova/+/948076 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Add spawn_on https://review.opendev.org/c/openstack/nova/+/948079 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Move ComputeManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948186 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Move ConductorManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948187 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Make nova.utils.pass_context private https://review.opendev.org/c/openstack/nova/+/948188 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Rename DEFAULT_GREEN_POOL to DEFAULT_EXECUTOR https://review.opendev.org/c/openstack/nova/+/948086 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Make the default executor configurable https://review.opendev.org/c/openstack/nova/+/948087 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Print ThreadPool statistics https://review.opendev.org/c/openstack/nova/+/948340 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Document threading mode and tuneables https://review.opendev.org/c/openstack/nova/+/949364 | 09:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: WIP: allow service to start with threading https://review.opendev.org/c/openstack/nova/+/948311 | 09:50 |
| 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:50 |
| 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:52 |
| sean-k-mooney | Uggla: sure im aboot to kick off a vm os install so ill finsih that and then take a look | 09:55 |
| Uggla | sean-k-mooney, thx no hurries at all. | 09:56 |
| Uggla | This is more to not forget about it. | 09:56 |
| sean-k-mooney | i raced with gibi | 10:02 |
| sean-k-mooney | its on its way now | 10:02 |
| opendevreview | Merged openstack/nova master: Mention IRC topic update in PTL post-PTG checklist https://review.opendev.org/c/openstack/nova/+/949711 | 10:20 |
| gibi | :) | 10:36 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Document threading mode and tuneables https://review.opendev.org/c/openstack/nova/+/949364 | 10:46 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: WIP: allow service to start with threading https://review.opendev.org/c/openstack/nova/+/948311 | 10: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 | 10:47 |
| 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 |
| gibi | series starts here https://review.opendev.org/c/openstack/nova/+/947966 | 12:04 |
| sean-k-mooney | ack, whats the status fo the oslo threading backend | 12:04 |
| sean-k-mooney | are we still waiting on an inital release with that supprot? | 12:05 |
| 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:05 |
| gibi | sean-k-mooney: yeah we waiting for the merge and release | 12:08 |
| gibi | there is good progress on the patch and has one +2 | 12:09 |
| gibi | so it is not far behind | 12:09 |
| sean-k-mooney | ack. i see the previous run on the first patch was green how has the ci stablity been so far | 12:10 |
| 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 |
| gibi | bunch of :) | 12:11 |
| gibi | and I ran them locally obviously | 12:12 |
| 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 |
| gibi | in nova-next | 12:13 |
| 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 |
| gibi | I will keep monitoring the results | 12:14 |
| 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 |
| gibi | the author is responsive, he fixed couple of issue I reported and did improvements for us | 12:15 |
| gibi | he is planning for folluw up patches based on recent non blocking comments | 12:16 |
| sean-k-mooney | that all sounds good | 12:17 |
| 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 |
| gibi | same is true for the doc gen target as well | 12:17 |
| sean-k-mooney | well | 12:18 |
| sean-k-mooney | the docs is only ture if we are auto generating the config docs | 12:18 |
| sean-k-mooney | liek it shoudl work with the old version but not render the new options right | 12:18 |
| sean-k-mooney | or perhaps not | 12:19 |
| 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 |
| sean-k-mooney | it kind of depend on what code paths we are hitting | 12:19 |
| sean-k-mooney | ah ok | 12:19 |
| 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 |
| sean-k-mooney | i.e. we disable monkeypatching in the docs env due to the multiple imports | 12:20 |
| sean-k-mooney | that and well we dont need to monkey patch sphinx build | 12:20 |
| sean-k-mooney | /need/want/ | 12:21 |
| gibi | yeah it is similar | 12:21 |
| gibi | but it will work OK as soon as the open oslo.service patch released | 12:21 |
| 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:21 |
| 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:23 |
| sean-k-mooney | but cool none of that sounds concerning to me | 12:24 |
| gibi | sean-k-mooney: btw, could you check https://review.opendev.org/c/openstack/devstack/+/948436 as well? | 12:24 |
| gibi | that is the small devstack patch to make it possible to pass env variables from zuul.yaml to systemd | 12:26 |
| 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:26 |
| sean-k-mooney | gibi: i looked at that when you first pushed it so im +1 on it still | 12:27 |
| gibi | thanks | 12:27 |
| sean-k-mooney | gibi: since we are talking about devstack https://review.opendev.org/c/openstack/devstack/+/939825 | 12:28 |
| sean-k-mooney | do you have time to adress frickler's comment | 12:28 |
| sahid | sean-k-mooney, bauzas o/ | 12:28 |
| sahid | anychance that you have a look into that one when you have a moement https://review.opendev.org/c/openstack/nova/+/947804 | 12:28 |
| sahid | looks reasonable and easy fix to backport | 12:29 |
| gibi | sean-k-mooney: yepp that is on my radar to reply | 12:29 |
| sahid | it does not basically fix the root cause but that seems reasonable, as fixing that unsync would be quite difficult I guess | 12:30 |
| sean-k-mooney | sahid: so doing the firsterign in python is not really what we want here | 12:31 |
| sean-k-mooney | limit is a max its nto nessiarly what you will recive | 12:32 |
| 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:32 |
| sahid | does that make sense? | 12:33 |
| sahid | basically the pagination is not working and we can print the other instances | 12:33 |
| sahid | s/can/can't | 12:33 |
| 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 |
| sean-k-mooney | as that break paging | 12:34 |
| sean-k-mooney | wther we shoudl be returnign 6 or 7 results is open for debate | 12:34 |
| sean-k-mooney | but the marker being missing is defintlly wrong | 12:35 |
| sahid | yep we are on the same page :-) | 12:35 |
| sahid | sean-k-mooney: you indicated it as low, but this can break many apps, e.g: workflow used to compute billing | 12:40 |
| 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:41 |
| sahid | ack thanks ! | 12:42 |
| 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:54 |
| 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:58 |
| 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 |
| opendevreview | Stephen Finucane proposed openstack/nova-specs master: Add flavor-search-by-name spec https://review.opendev.org/c/openstack/nova-specs/+/940440 | 13:00 |
| sahid | sean-k-mooney: thank you for that review, hoppefuly amorin will have a look ;-) | 13:12 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Allow services to start with threading https://review.opendev.org/c/openstack/nova/+/948311 | 13:13 |
| 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:13 |
| 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:14 |
| amorin | thanks for review, I will have a look | 13:16 |
| *** haleyb|out is now known as haleyb | 13:41 | |
| Uggla | bauzas, your work on mtty. Does it allow to get rid of compile_mdev_samples ? | 15:17 |
| Uggla | dansmith, I have a question about OTU. I think youd use real nvme devices for testing ? Am I right ? | 15:24 |
| dansmith | Uggla: are you asking if I have tested it with real nvme devices? | 15:25 |
| Uggla | dansmith, yes | 15:30 |
| Uggla | or did you simulated them with qemu ? | 15:31 |
| dansmith | Uggla: no, I'm using real NVMes | 15:34 |
| dansmith | Uggla: but you can use OTU with any PCI device for testing | 15:34 |
| dansmith | when I started I was using the vRNG | 15:34 |
| 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 |
| dansmith | yeah idk, perhaps | 15:35 |
| Uggla | or testing... | 15:35 |
| 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 |
| dansmith | but for just the nova plumbing, it will probably be enough | 15:36 |
| Uggla | dansmith, thx. | 15:43 |
| 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 | 15:55 |
| Uggla | frickler, damned not cool. | 15:58 |
| opendevreview | Dan Smith proposed openstack/nova master: Revert "Support glance's new location API" https://review.opendev.org/c/openstack/nova/+/950336 | 15:59 |
| Uggla | frickler, does that mean we should try to speed up a bit on the pkg_resources replacement patch ? | 16:07 |
| bauzas | Uggla: dansmith: sean-k-mooney: weirdo, I created a devstack host with mtty on noble, it worked fine | 16:26 |
| frickler | bauzas: did that include designate? | 16:26 |
| frickler | Uggla: to me it looks like your fix for the uc-check is masking a real issue for consumers of the affected oslo libs | 16:27 |
| johnsom | +1 | 16:27 |
| frickler | but maybe we should move to reqs or oslo channel for further discussion | 16:28 |
| bauzas | frickler: nope | 16:28 |
| frickler | bauzas: ah, different topic, sorry I misread that comment | 16:30 |
| bauzas | I stupidely forgot to ask in local.conf to file the devstack log, so I'm just recloning my instance to see how it worked when creating the kernel examples | 16:31 |
| Uggla | frickler, ok I wonder how it can worsen the situation because it only act if we get an exception. But I agree it can make identifying the real root cause more difficult. | 16:34 |
| frickler | Uggla: so my current theory is that the oslo.utils 7.3.1 release is somehow broken, the reqs check noticed that and prevented it from getting into u-c, so maybe your fix that resolved that block isn't a real fix. need to do more digging tomorrow or maybe help from oslo or release ppl | 16:42 |
| Uggla | frickler, ok let me know if you need my help. | 16:43 |
| bauzas | ah, stupid I am : | 16:59 |
| bauzas | stack@sbauza-mtty-ubuntu:~/nova$ uname -r | 16:59 |
| bauzas | 6.8.0-35-generic | 16:59 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Add mtty/mdpy support for testing fake mdevs https://review.opendev.org/c/openstack/nova/+/898100 | 17:11 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: WIP : Add mtty support to nova-next https://review.opendev.org/c/openstack/nova/+/922140 | 17:11 |
| sean-k-mooney | bauzas: they may have fixed the mirros | 19:34 |
| sean-k-mooney | bauzas: i would suggest prposint a revert the disable patch | 19:35 |
| sean-k-mooney | and see if it starts passign in ci again | 19:35 |
| sean-k-mooney | ah yuou have in https://review.opendev.org/c/openstack/nova/+/922140/21/.zuul.yaml | 19:36 |
| sean-k-mooney | bauzas: that failing with May 19 17:59:54.847711 np0040813405 nova-compute[41390]: ERROR nova nova.exception.InvalidLibvirtMdevConfig: Invalid configuration for mdev-capable devices: incorrect PCI address: mtty_mtty | 19:38 |
| sean-k-mooney | so its compiling fine now but there is either a bug in the previous patch https://review.opendev.org/c/openstack/nova/+/898100/10 os somethign with how you configured the job | 19:39 |
| sean-k-mooney | oh im also seeign libvirt.libvirtError: Cannot find 'mdevctl' in path: No such file or directory | 19:40 |
| sean-k-mooney | bauzas: mell was tryign to adress that in https://review.opendev.org/c/openstack/nova/+/948581/6 | 19:41 |
| opendevreview | melanie witt proposed openstack/nova master: DNM try to install mdevctl https://review.opendev.org/c/openstack/nova/+/948581 | 19:41 |
| sean-k-mooney | i just rebased ^ on top of your latest revision so let see if that helps. if it does you can squah it into your second patch | 19:42 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!