Tuesday, 2022-10-04

opendevreviewTobias Urdin proposed openstack/blazar master: [WIP] Test async  https://review.opendev.org/c/openstack/blazar/+/85893807:33
tobias-urdinyoctozepto: semi-working poc now https://review.opendev.org/c/openstack/blazar/+/858938 – some notes, only for v1 and abusing that flask>=2.0 can run async funcs, disables the event thread running by eventlet for now so everything is not working since those events is not called07:35
yoctozeptotobias-urdin: oh, I see; regarding the v2 api - we will be removing it this cycle so no sweat in there; anyways, seems like this went worse than expected ;d I can't even imagine the pain with nova, ouch!07:41
yoctozeptounless we figure out and document all the patterns and then apply some machinery to detect and replace them07:42
yoctozeptoI don't think it will be feasible to ever switch...07:42
yoctozeptoand thanks for working on this! I still seem unable to find a meaningful time pool to get something sensible done in that regard...07:42
tobias-urdinyoctozepto: yeah it gets worse as well, different api frameworks (flask vs pecan) would be easier if there was a oslo framework for that :p08:27
tobias-urdinit's also the question about wsgi vs asgi, so no more mod_wsgi, uwsgi etc and run async services with hypercorn and so on08:28
tobias-urdinand this doesn't even accounts for the fact about internal usage of synchronous code, porting oslo.db etc08:29
tobias-urdinso IMO we would be better off just porting an synchronous version of nats-py with just the bare minimum that is needed08:29
tobias-urdinbut yeah when we are talking about removing eventlet and threading in favor of async we are taking on a real beast so to speak08:31
tobias-urdini'm actually quite suprised there was no effort in past to introduce an api framework into oslo, since there was and is a lot of back and forth "move to pecan", "move to flask" etc specs everywhere08:33
yoctozeptotobias-urdin: agreed08:54
yoctozeptohi hberaud 08:54
yoctozeptoI wonder how feasible it is to actually try to maintain a bare minimum of NATS eventlet-compatible library08:55
yoctozeptoor in other words08:55
yoctozeptohow much of the official library we don't need ;d08:55
tobias-urdinnot sure, but it's not much, publish, subscribe and wait logic i guess09:08
tobias-urdinthat would also support notifications part of oslo.messaging09:08
tobias-urdinif we want locking or key-value store for oslo.cache we would need jetstream and KV part09:09
tobias-urdini was actually contacted by the employeer of the maintainer for nats-py, maybe I should ask them09:15
tobias-urdinlets see if I get a reply09:22
hberaudWhat's about acknowledgements, queues etc? These features are not provided by nats.py, but they are brings by stan.py (https://github.com/nats-io/stan.py), so that mean maintaining at least 2 libs, one for the basic feature and the other for advanced usages like did by the combo nats.py/stan.py10:28
hberaudIf our goal is to replace rabbitmq and the oslo.messaging rabbitmq driver I think we need to use stan.py through the oslo.messaging nats driver10:29
tobias-urdinhberaud: actually depends, the two implementations I've demonstrated for a NATS driver uses queue groups, which ensures only one listener gets the message and not the default 1 to many gets used11:11
tobias-urdinregarding acknolwedgements then yes, there is no such thing unless using jetstream but then again, if a backend doesn't respond to a RPC why couldn't the client side just send again with a resonable timeout11:11
tobias-urdinfor persistence there is no such thing unless we use jetstream so the question is really do we really need to mimic rabbitmq or implement it the way it was demonstrated with a lot of improvements that is11:12
hberaudI agreed, you are right, mimic rabbitmq is a bad idea11:16
tobias-urdinI understand your point tho, it's still possible to mimic rabbit, I just don't see the benefit to have that as a requirement for a new technology11:25
hberaudI'm aligned with that. However this philosphy should be strongly bolded because operators and lot of people risk to ask to mimic the existing driver11:26
tobias-urdinhberaud: sorry for late reply, yes I agree13:42
hberaud"implement it the way it was demonstrated" should be the DNA of this new driver13:43
hberaudthen I'll update the specs to bold that13:44

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