| *** dkehn_ is now known as dkehn | 01:06 | |
| opendevreview | OpenStack Proposal Bot proposed openstack/oslo.cache master: Imported Translations from Zanata https://review.opendev.org/c/openstack/oslo.cache/+/856000 | 03:18 |
|---|---|---|
| opendevreview | Merged openstack/oslo.concurrency master: Prove that spawn_n with fair lock is broken https://review.opendev.org/c/openstack/oslo.concurrency/+/855713 | 09:18 |
| opendevreview | Merged openstack/oslo.concurrency master: Fix fair internal lock used from eventlet.spawn_n https://review.opendev.org/c/openstack/oslo.concurrency/+/855714 | 09:30 |
| opendevreview | Merged openstack/oslo.concurrency master: Ignore coverage result files https://review.opendev.org/c/openstack/oslo.concurrency/+/855716 | 09:30 |
| sean-k-mooney | hberaud: gibi im happy that ^ has been merged looping back to fasteners | 09:52 |
| sean-k-mooney | https://github.com/harlowja/fasteners/pull/97 | 09:53 |
| sean-k-mooney | im pretty sure i can do what they ask without too much troble | 09:53 |
| sean-k-mooney | if i submit a patch to oslo for that have you and object to oslo detecting if eventlets is used and passing the fuctor to the ReaderWriterLock constructor | 09:54 |
| hberaud | Then I'm going to release oslo.concurrency | 09:55 |
| sean-k-mooney | hberaud: ya i would release withthe version that is merged and then early next cycle i can add support in fasteners and oslo to do it the "upstream" way | 09:56 |
| sean-k-mooney | i dont really want us to wait for a fasterns release | 09:56 |
| sean-k-mooney | so i think the oslo release makes sesnse for zed | 09:57 |
| hberaud | WFM | 09:57 |
| hberaud | I'll request a RFE first | 09:57 |
| sean-k-mooney | RFE or FFE | 09:58 |
| hberaud | FFE :) | 09:58 |
| sean-k-mooney | ok i was worried for a sec that i missed something importnat | 09:58 |
| hberaud | However, this not a feature, so I don't think I need to request that | 09:58 |
| hberaud | so at least I think I need a rfe | 09:59 |
| sean-k-mooney | well its a bug fix/workaroudn fo an upstream lib incompatiblity so you just need to request an expction form the release team for the non client lib freeze restrictions i think. although you have done this more often then i have so im sure you have got this. im going to update the upstream pull request and ill start on some patches to both repos today | 10:02 |
| hberaud | Well, I missed that oslo.concurrency is an independent deliverable, so we don't need requesting something | 10:05 |
| sean-k-mooney | the only thing that will be needed is to allow it in upper constraits | 10:06 |
| hberaud | https://review.opendev.org/c/openstack/releases/+/856037 | 10:07 |
| hberaud | yes | 10:07 |
| hberaud | I'll prepare a patch for the requirements update and discuss that with the team | 10:08 |
| hberaud | stephenfin: o/ Do you mind to have a look to https://review.opendev.org/c/openstack/oslo.config/+/855333 . Thanks in advance | 13:32 |
| stephenfin | hberaud: done | 13:34 |
| hberaud | thanks | 13:34 |
| opendevreview | sean mooney proposed openstack/oslo.concurrency master: Add support for passing current_thread_functor to fasteners https://review.opendev.org/c/openstack/oslo.concurrency/+/856120 | 13:48 |
| abishop | hberaud, damani: hi, me again :D | 14:22 |
| abishop | with https://review.opendev.org/c/openstack/tooz/+/827492 merged, I'm requesting a new tooz release | 14:22 |
| hberaud | abishop: https://review.opendev.org/c/openstack/releases/+/856128 | 14:36 |
| abishop | hberaud: thx! | 14:37 |
| hberaud | np | 14:38 |
| dtantsur | stephenfin: hi! is there a list of changes in oslo.db 12.1.0? the release notes are a bit light on details | 14:55 |
| dtantsur | I'm looking at https://review.opendev.org/c/openstack/ironic/+/855969 now, and trying to understand why it fixes tests that have nothing to do with committing anything. | 14:56 |
| dtantsur | Without understanding it, we cannot replace the use of autocommit | 14:56 |
| stephenfin | dtantsur: The only significant change is that autocommit change. I don't have a local copy of ironic, but a run of the unit tests with the warnings enabled for that particular issue should highlight the autocommit-requiring code https://review.opendev.org/c/openstack/nova/+/837161/1/nova/tests/fixtures/nova.py | 14:58 |
| dtantsur | hmm, I wonder how it looks for the PYTHONWARNINGS variable | 14:59 |
| dtantsur | or rather: I think our testing tools "helpfully" swallow any warnings :( | 15:00 |
| dtantsur | actually, no, they do not | 15:02 |
| dtantsur | stephenfin: I don't see any warnings in the affected tests | 15:02 |
| stephenfin | Hmm, that's odd. It would appear my fix is doing the correct thing since I see green https://review.opendev.org/c/openstack/requirements/+/855973/ so I guess it's a case of reverse engineering the reason why it fixes things | 15:06 |
| dtantsur | that's what I'm doing now :) | 15:07 |
| dtantsur | yeah, your fix seems to work, I don't know why | 15:07 |
| dtantsur | OR I'm still unable to turn SA warnings on | 15:07 |
| stephenfin | And just because it's worth asking, ironic is definitely broken with oslo.db 12.1.0, yeah? As in, those gate failures weren't flakes? | 15:09 |
| dtantsur | stephenfin: I consistently reproduce the unit test failures locally | 15:09 |
| stephenfin | Okay, good to know | 15:10 |
| opendevreview | Merged openstack/oslo.config stable/yoga: Disable a config test if ran under the root user https://review.opendev.org/c/openstack/oslo.config/+/855333 | 15:11 |
| dtantsur | stephenfin: okay, this is causing me headache, so I'll probably just approve your workaround for now.. | 15:16 |
| opendevreview | mike_mp@zzzcomputing.com proposed openstack/oslo.db master: remove sqlalchemy-migrate https://review.opendev.org/c/openstack/oslo.db/+/853025 | 15:47 |
| sean-k-mooney | yoctozepto: by the way droping eventlet form nova while desireable is basicaly a major rewrite | 17:13 |
| sean-k-mooney | yoctozepto: im not convinced using pthread is safe under a wsign server either by the way wit eventlets | 17:14 |
| sean-k-mooney | for nova compute we have seen the agent hang if there is a rabbitmq disconenct which makes me think thre is some issue with eventlet and multiple threads that only shows up in the expction path | 17:17 |
| sean-k-mooney | anyway if you turn off eventlet monkey patching today nova will fail to work. we have also relied on io causing thing to yeild in many cases so that would be hard to unravel | 17:19 |
| yoctozepto | sean-k-mooney: | 17:20 |
| yoctozepto | sean-k-mooney: I was afraid it might be like this for nova | 17:21 |
| sean-k-mooney | nova, swift cinder and neutron | 17:22 |
| yoctozepto | regarding pthread in wsgi - I don't know but we basically recommend using pthread for heartbeats with wsgi... | 17:22 |
| sean-k-mooney | honestly i would recommend removing that feature | 17:22 |
| sean-k-mooney | it has no real useful benifit in the wsgi context | 17:23 |
| sean-k-mooney | the reason it was added was to silence the warning message | 17:23 |
| yoctozepto | well, the warning was about dying connections which is an inconvenience still, no? | 17:23 |
| sean-k-mooney | that was cause because the wsgi server kills the thread after the reponce is processed | 17:23 |
| sean-k-mooney | its annoying in the logs if you dont filter it | 17:23 |
| sean-k-mooney | but that its | 17:24 |
| sean-k-mooney | where as the pthread actully breaks things | 17:24 |
| sean-k-mooney | which is why the default was reverted to off | 17:24 |
| yoctozepto | odd, it should be perfect for heartbeats | 17:24 |
| sean-k-mooney | it does not only get used for heat beats | 17:25 |
| sean-k-mooney | eventlet end up something resuming greanthreads/greenlets on it | 17:25 |
| sean-k-mooney | its why we cant run many of the services with multipel threads under wsgi | 17:25 |
| sean-k-mooney | and why we have to use multipel processes | 17:25 |
| sean-k-mooney | this seams to be an issue for any wsgi service that also has rabbit | 17:26 |
| sean-k-mooney | keystone and palcment dont seeam to have the same issues | 17:26 |
| sean-k-mooney | so i suspect there is an interaction between pthreads and the rabbitmq driver and eventlet | 17:26 |
| yoctozepto | oh, could be | 17:27 |
| yoctozepto | well, the monkey patching is monkey business :-) | 17:27 |
| sean-k-mooney | :) | 17:27 |
| sean-k-mooney | so the rabbit driver is using threading directly | 17:28 |
| sean-k-mooney | https://github.com/eventlet/eventlet/issues/731#issuecomment-969891721 | 17:29 |
| sean-k-mooney | but as melwitt found that has non intuitive behvior | 17:29 |
| sean-k-mooney | the beahvior of swpan spawn_n is not the same | 17:30 |
| sean-k-mooney | and Thread.start() resolts in calling spawn_n | 17:30 |
| sean-k-mooney | spawn_n is nerver ment to return | 17:31 |
| sean-k-mooney | which means you can never allow any uncaut exctpion ot escape the sart funciton or its undefiend behavior | 17:31 |
| sean-k-mooney | im not certin but if https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/amqpdriver.py#L72-L80 raises an excption from task() | 17:40 |
| sean-k-mooney | i think that is technially a bug | 17:40 |
| sean-k-mooney | based on https://eventlet.net/doc/modules/greenthread.html#eventlet.greenthread.spawn_n | 17:42 |
| sean-k-mooney | this is also relate dto https://bugs.launchpad.net/oslo.messaging/+bug/1949964 and https://bugs.launchpad.net/oslo.messaging/+bug/1934937 | 17:44 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!