| opendevreview | Tobias Urdin proposed openstack/blazar master: [WIP] Test async https://review.opendev.org/c/openstack/blazar/+/858938 | 07:33 |
|---|---|---|
| tobias-urdin | yoctozepto: 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 called | 07:35 |
| yoctozepto | tobias-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 |
| yoctozepto | unless we figure out and document all the patterns and then apply some machinery to detect and replace them | 07:42 |
| yoctozepto | I don't think it will be feasible to ever switch... | 07:42 |
| yoctozepto | and 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-urdin | yoctozepto: yeah it gets worse as well, different api frameworks (flask vs pecan) would be easier if there was a oslo framework for that :p | 08:27 |
| tobias-urdin | it's also the question about wsgi vs asgi, so no more mod_wsgi, uwsgi etc and run async services with hypercorn and so on | 08:28 |
| tobias-urdin | and this doesn't even accounts for the fact about internal usage of synchronous code, porting oslo.db etc | 08:29 |
| tobias-urdin | so IMO we would be better off just porting an synchronous version of nats-py with just the bare minimum that is needed | 08:29 |
| tobias-urdin | but yeah when we are talking about removing eventlet and threading in favor of async we are taking on a real beast so to speak | 08:31 |
| tobias-urdin | i'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 everywhere | 08:33 |
| yoctozepto | tobias-urdin: agreed | 08:54 |
| hberaud | o/ | 08:54 |
| yoctozepto | hi hberaud | 08:54 |
| yoctozepto | I wonder how feasible it is to actually try to maintain a bare minimum of NATS eventlet-compatible library | 08:55 |
| yoctozepto | or in other words | 08:55 |
| yoctozepto | how much of the official library we don't need ;d | 08:55 |
| tobias-urdin | not sure, but it's not much, publish, subscribe and wait logic i guess | 09:08 |
| tobias-urdin | that would also support notifications part of oslo.messaging | 09:08 |
| tobias-urdin | if we want locking or key-value store for oslo.cache we would need jetstream and KV part | 09:09 |
| tobias-urdin | i was actually contacted by the employeer of the maintainer for nats-py, maybe I should ask them | 09:15 |
| tobias-urdin | lets see if I get a reply | 09:22 |
| hberaud | What'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.py | 10:28 |
| hberaud | If 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 driver | 10:29 |
| tobias-urdin | hberaud: 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 used | 11:11 |
| tobias-urdin | regarding 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 timeout | 11:11 |
| tobias-urdin | for 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 is | 11:12 |
| hberaud | I agreed, you are right, mimic rabbitmq is a bad idea | 11:16 |
| tobias-urdin | I 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 technology | 11:25 |
| hberaud | I'm aligned with that. However this philosphy should be strongly bolded because operators and lot of people risk to ask to mimic the existing driver | 11:26 |
| tobias-urdin | hberaud: sorry for late reply, yes I agree | 13:42 |
| hberaud | "implement it the way it was demonstrated" should be the DNA of this new driver | 13:43 |
| hberaud | then I'll update the specs to bold that | 13:44 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!