Re: [all] [oslo.messaging] Interest in collaboration on a NATS driver
Hello Kai,
Great to hear that you’re interested! I’m currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens kb@kbojens.de wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I’m hoping somebody will bite but atleast I’ve put it out there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and test your code?
Greetings, Kai
+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin tobias.urdin@binero.com a écrit :
Hello Kai,
Great to hear that you’re interested! I’m currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens kb@kbojens.de wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in
collaborating in a project to bring this support and maintain it feel free to
reach out. I’m hoping somebody will bite but atleast I’ve put it out
there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe
contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS and
your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and test
your code?
Greetings, Kai
I have just got to read the documentation of NATS and I think it's the right choice for doing RPC in OpenStack. Let's do this. Count me in as well.
For RPC, I think we should base ourselves off the Request-Reply [1] and Queue Groups [2] functionalities of NATS.
Regarding tradeoffs, it seems the ones NATS took are favorable in our use case (specifically, having a simple protocol with simple semantics).
As I commented on the new NATS WIP changes, we need to revive the old NATS spec (probably as a new change though). I suggest following the (old) advice of Sean to focus on RPC, especially since NATS Core is more suitable for RPC than notifications.
[1] https://docs.nats.io/nats-concepts/core-nats/reqreply [2] https://docs.nats.io/nats-concepts/core-nats/queue
Cheers, Radek -yoctozepto
On Thu, 1 Sept 2022 at 16:11, Herve Beraud hberaud@redhat.com wrote:
+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin tobias.urdin@binero.com a écrit :
Hello Kai,
Great to hear that you’re interested! I’m currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens kb@kbojens.de wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I’m hoping somebody will bite but atleast I’ve put it out there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and test your code?
Greetings, Kai
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
+1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin mailto:tobias.urdin@binero.com a écrit : Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens mailto:kb@kbojens.de wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and test your code?
Greetings, Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hierhttps://www.datenschutz.schwarz.
Thanks! It seems that we have some traction here to get started in a more structured manner.
I’m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic? I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec.
Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us!
Best regards Tobias
On 2 Sept 2022, at 10:35, Felix Hüttner felix.huettner@mail.schwarz wrote:
+1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin mailto:tobias.urdin@binero.com a écrit : Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens mailto:kb@kbojens.de wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and test your code?
Greetings, Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hierhttps://www.datenschutz.schwarz.
Le lun. 5 sept. 2022 à 10:00, Tobias Urdin tobias.urdin@binero.com a écrit :
Thanks! It seems that we have some traction here to get started in a more structured manner.
I’m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic?
The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo
You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management.
I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec.
Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us!
Best regards Tobias
On 2 Sept 2022, at 10:35, Felix Hüttner felix.huettner@mail.schwarz
wrote:
+1, we would also be interested in helping out. Let me know where we can
help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py to
see how it works and I'm volunteering to go further with this technology.
Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin <mailto:
tobias.urdin@binero.com> a écrit :
Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so there
is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens mailto:kb@kbojens.de wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in
collaborating in a project to bring this support and maintain it feel free to
reach out. I'm hoping somebody will bite but atleast I've put it out
there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe
contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS
and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and
test your code?
Greetings, Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für
die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hierhttps://www.datenschutz.schwarz.
Great! I’ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material:
- Current POC code https://review.opendev.org/c/openstack/oslo.messaging/+/848338 - Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats - Discussion on IRC on 2nd September about below links https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.202...https://meetings.opendev.org/irclogs/#openstack-oslo/#openstack-oslo.2022-09-02.log.html
Links to old material: - The old spec that we can work upon https://review.opendev.org/c/openstack/oslo-specs/+/692784 - Old driver implementation for above old spec https://review.opendev.org/c/openstack/oslo.messaging/+/680629 - Old asyncio planning https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio - Old asyncio executor in oslo.messaging https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor - Old messaging API mail thread https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html
Looking forward to talk to you all next monday!
Best regards Tobias
On 5 Sept 2022, at 12:48, Herve Beraud <hberaud@redhat.commailto:hberaud@redhat.com> wrote:
Le lun. 5 sept. 2022 à 10:00, Tobias Urdin <tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Thanks! It seems that we have some traction here to get started in a more structured manner.
I’m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic?
The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo
You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management.
I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec.
Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us!
Best regards Tobias
On 2 Sept 2022, at 10:35, Felix Hüttner <felix.huettner@mail.schwarzmailto:felix.huettner@mail.schwarz> wrote:
+1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin <mailto:tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens <mailto:kb@kbojens.demailto:kb@kbojens.de> wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and test your code?
Greetings, Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarzhttps://www.datenschutz.schwarz/>.
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
Hi Tobias et al,
That Monday I cannot attend due to other work commitments. Could we schedule it for the following week?
Cheers, Radek
On Tue, Sep 6, 2022, 18:33 Tobias Urdin tobias.urdin@binero.com wrote:
Great! I’ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material:
- Current POC code
https://review.opendev.org/c/openstack/oslo.messaging/+/848338
- Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats
- Discussion on IRC on 2nd September about below links
https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.202... https://meetings.opendev.org/irclogs/#openstack-oslo/%23openstack-oslo.2022-09-02.log.html
Links to old material:
- The old spec that we can work upon
https://review.opendev.org/c/openstack/oslo-specs/+/692784
- Old driver implementation for above old spec
https://review.opendev.org/c/openstack/oslo.messaging/+/680629
- Old asyncio planning
https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio
- Old asyncio executor in oslo.messaging
https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor
- Old messaging API mail thread
https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html
Looking forward to talk to you all next monday!
Best regards Tobias
On 5 Sept 2022, at 12:48, Herve Beraud hberaud@redhat.com wrote:
Le lun. 5 sept. 2022 à 10:00, Tobias Urdin tobias.urdin@binero.com a écrit :
Thanks! It seems that we have some traction here to get started in a more structured manner.
I’m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic?
The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo
You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management.
I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec.
Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us!
Best regards Tobias
On 2 Sept 2022, at 10:35, Felix Hüttner felix.huettner@mail.schwarz
wrote:
+1, we would also be interested in helping out. Let me know where we
can help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py
to see how it works and I'm volunteering to go further with this technology.
Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin <mailto:
tobias.urdin@binero.com> a écrit :
Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so there
is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens mailto:kb@kbojens.de wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in
collaborating in a project to bring this support and maintain it feel free to
reach out. I'm hoping somebody will bite but atleast I've put it out
there for all of you.
Hi, I am very much interested to take a closer look at your work and
maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS
and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and
test your code?
Greetings, Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur
für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hierhttps://www.datenschutz.schwarz.
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
Hello,
I don’t have anything against moving to the 19th of September meeting if that’s OK with everybody else, I propose we do that.
Let’s see if we get some feedback against the proposed new date otherwise we’ll move it.
Best regards
On 8 Sept 2022, at 08:41, Radosław Piliszek <radoslaw.piliszek@gmail.commailto:radoslaw.piliszek@gmail.com> wrote:
Hi Tobias et al,
That Monday I cannot attend due to other work commitments. Could we schedule it for the following week?
Cheers, Radek
On Tue, Sep 6, 2022, 18:33 Tobias Urdin <tobias.urdin@binero.commailto:tobias.urdin@binero.com> wrote: Great! I’ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material:
- Current POC code https://review.opendev.org/c/openstack/oslo.messaging/+/848338 - Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats - Discussion on IRC on 2nd September about below links https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.202...https://meetings.opendev.org/irclogs/#openstack-oslo/%23openstack-oslo.2022-09-02.log.html
Links to old material: - The old spec that we can work upon https://review.opendev.org/c/openstack/oslo-specs/+/692784 - Old driver implementation for above old spec https://review.opendev.org/c/openstack/oslo.messaging/+/680629 - Old asyncio planning https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio - Old asyncio executor in oslo.messaging https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor - Old messaging API mail thread https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html
Looking forward to talk to you all next monday!
Best regards Tobias
On 5 Sept 2022, at 12:48, Herve Beraud <hberaud@redhat.commailto:hberaud@redhat.com> wrote:
Le lun. 5 sept. 2022 à 10:00, Tobias Urdin <tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Thanks! It seems that we have some traction here to get started in a more structured manner.
I’m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic?
The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo
You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management.
I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec.
Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us!
Best regards Tobias
On 2 Sept 2022, at 10:35, Felix Hüttner <felix.huettner@mail.schwarzmailto:felix.huettner@mail.schwarz> wrote:
+1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin <mailto:tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens <mailto:kb@kbojens.demailto:kb@kbojens.de> wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and test your code?
Greetings, Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarzhttps://www.datenschutz.schwarz/>.
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
WFM
Le jeu. 8 sept. 2022 à 15:16, Tobias Urdin tobias.urdin@binero.com a écrit :
Hello,
I don’t have anything against moving to the 19th of September meeting if that’s OK with everybody else, I propose we do that.
Let’s see if we get some feedback against the proposed new date otherwise we’ll move it.
Best regards
On 8 Sept 2022, at 08:41, Radosław Piliszek radoslaw.piliszek@gmail.com wrote:
Hi Tobias et al,
That Monday I cannot attend due to other work commitments. Could we schedule it for the following week?
Cheers, Radek
On Tue, Sep 6, 2022, 18:33 Tobias Urdin tobias.urdin@binero.com wrote:
Great! I’ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material:
- Current POC code
https://review.opendev.org/c/openstack/oslo.messaging/+/848338
- Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats
- Discussion on IRC on 2nd September about below links
https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.202... https://meetings.opendev.org/irclogs/#openstack-oslo/%23openstack-oslo.2022-09-02.log.html
Links to old material:
- The old spec that we can work upon
https://review.opendev.org/c/openstack/oslo-specs/+/692784
- Old driver implementation for above old spec
https://review.opendev.org/c/openstack/oslo.messaging/+/680629
- Old asyncio planning
https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio
- Old asyncio executor in oslo.messaging
https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor
- Old messaging API mail thread
https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html
Looking forward to talk to you all next monday!
Best regards Tobias
On 5 Sept 2022, at 12:48, Herve Beraud hberaud@redhat.com wrote:
Le lun. 5 sept. 2022 à 10:00, Tobias Urdin tobias.urdin@binero.com a écrit :
Thanks! It seems that we have some traction here to get started in a more structured manner.
I’m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic?
The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo
You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management.
I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec.
Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us!
Best regards Tobias
On 2 Sept 2022, at 10:35, Felix Hüttner felix.huettner@mail.schwarz
wrote:
+1, we would also be interested in helping out. Let me know where we
can help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py
to see how it works and I'm volunteering to go further with this technology.
Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin <mailto:
tobias.urdin@binero.com> a écrit :
Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so
there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens mailto:kb@kbojens.de wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
> If anybody, or any company, out there would be interested in
collaborating in a project to bring this support and maintain it feel free to
> reach out. I'm hoping somebody will bite but atleast I've put it
out there for all of you.
Hi, I am very much interested to take a closer look at your work and
maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS
and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and
test your code?
Greetings, Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur
für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hierhttps://www.datenschutz.schwarz.
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
Hello,
Since I haven’t heard any objections we’ll move the meeting to the Oslo meeting on the 19th of September. See you there! [1]
[1] https://wiki.openstack.org/wiki/Meetings/Oslo
Best regards Tobias
On 8 Sept 2022, at 15:54, Herve Beraud <hberaud@redhat.commailto:hberaud@redhat.com> wrote:
WFM
Le jeu. 8 sept. 2022 à 15:16, Tobias Urdin <tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Hello,
I don’t have anything against moving to the 19th of September meeting if that’s OK with everybody else, I propose we do that.
Let’s see if we get some feedback against the proposed new date otherwise we’ll move it.
Best regards
On 8 Sept 2022, at 08:41, Radosław Piliszek <radoslaw.piliszek@gmail.commailto:radoslaw.piliszek@gmail.com> wrote:
Hi Tobias et al,
That Monday I cannot attend due to other work commitments. Could we schedule it for the following week?
Cheers, Radek
On Tue, Sep 6, 2022, 18:33 Tobias Urdin <tobias.urdin@binero.commailto:tobias.urdin@binero.com> wrote: Great! I’ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material:
- Current POC code https://review.opendev.org/c/openstack/oslo.messaging/+/848338 - Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats - Discussion on IRC on 2nd September about below links https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.202...https://meetings.opendev.org/irclogs/#openstack-oslo/%23openstack-oslo.2022-09-02.log.html
Links to old material: - The old spec that we can work upon https://review.opendev.org/c/openstack/oslo-specs/+/692784 - Old driver implementation for above old spec https://review.opendev.org/c/openstack/oslo.messaging/+/680629 - Old asyncio planning https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio - Old asyncio executor in oslo.messaging https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor - Old messaging API mail thread https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html
Looking forward to talk to you all next monday!
Best regards Tobias
On 5 Sept 2022, at 12:48, Herve Beraud <hberaud@redhat.commailto:hberaud@redhat.com> wrote:
Le lun. 5 sept. 2022 à 10:00, Tobias Urdin <tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Thanks! It seems that we have some traction here to get started in a more structured manner.
I’m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic?
The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo
You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management.
I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec.
Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us!
Best regards Tobias
On 2 Sept 2022, at 10:35, Felix Hüttner <felix.huettner@mail.schwarzmailto:felix.huettner@mail.schwarz> wrote:
+1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin <mailto:tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens <mailto:kb@kbojens.demailto:kb@kbojens.de> wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and test your code?
Greetings, Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarzhttps://www.datenschutz.schwarz/>.
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
Hello,
I first would like to apologize for not keeping everybody in the loop but I’ve been very busy with a lot of work.
I just wanted to give a quick update on some potential progress.
First off, the Oslo meeting on the 19th of September ([1] log here) kicked us into a direction of how we could use the official nats.py python client [2] to talk to NATS as we quickly ruled out the nats-python client [3] as it’s pretty unmaintained and incomplete.
We did however get a working POC driver [4] (see patchset 14) with [3] that confirmed we could get a Devstack job working even though the driver missed a lot of critical functionality such as error handling, retries, TLS etc etc.
Since the nats.py client [2] is asyncio based we investigated a path forward that meant where we could utilize asyncio in the oslo.messaging library and expose an API up to projects consuming oslo.messaging.
We decided to do some POC patches into oslo.messaging and using the Blazar project as a testing ground [4]. We very quickly found ourselves digging into oslo.service to implement asyncio, checking SQLAlchemy for support, API frameworks would need asyncio support, moving from WSGI to an ASGI compatible server, duplicating code for supporting sync and async code paths and more.
We came to the conclussion that introducing a NATS oslo.messaging driver meant requiring us to implement asyncio across our ecosystem which would take an massive effort. Some good came out of it in form of a patch [5] further improving the consistency of the oslo.messaging API, we also gained a lot of insight in the future if we would like to start introducing asyncio functionality into oslo projects to support it for the future.
Now moving forward to today.
I’ve talked with the maintainer of nats.py and the company behind him to investigate if we can include a synchronous code path into that Python library to be used in a future revision of a oslo.messaging NATS driver. Hopefully we’ll have some more progress to report on that in the beginning of next year.
Feel free to reach out to me (here or on IRC, my nick is tobias-urdin) if you want to know more, have any questions or want to get involved in anything I’ve mentioned above!
Best regards Tobias
[1] https://meetings.opendev.org/meetings/oslo/2022/oslo.2022-09-19-15.12.log.tx... [2] https://github.com/nats-io/nats.py [3] https://github.com/Gr1N/nats-python [4] https://review.opendev.org/q/topic:asyncio-nats [5] https://review.opendev.org/c/openstack/oslo.messaging/+/862419
On 12 Sep 2022, at 09:05, Tobias Urdin tobias.urdin@binero.com wrote:
Hello,
Since I haven’t heard any objections we’ll move the meeting to the Oslo meeting on the 19th of September. See you there! [1]
[1] https://wiki.openstack.org/wiki/Meetings/Oslo
Best regards Tobias
On 8 Sept 2022, at 15:54, Herve Beraud <hberaud@redhat.commailto:hberaud@redhat.com> wrote:
WFM
Le jeu. 8 sept. 2022 à 15:16, Tobias Urdin <tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Hello,
I don’t have anything against moving to the 19th of September meeting if that’s OK with everybody else, I propose we do that.
Let’s see if we get some feedback against the proposed new date otherwise we’ll move it.
Best regards
On 8 Sept 2022, at 08:41, Radosław Piliszek <radoslaw.piliszek@gmail.commailto:radoslaw.piliszek@gmail.com> wrote:
Hi Tobias et al,
That Monday I cannot attend due to other work commitments. Could we schedule it for the following week?
Cheers, Radek
On Tue, Sep 6, 2022, 18:33 Tobias Urdin <tobias.urdin@binero.commailto:tobias.urdin@binero.com> wrote: Great! I’ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material:
- Current POC code https://review.opendev.org/c/openstack/oslo.messaging/+/848338 - Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats - Discussion on IRC on 2nd September about below links https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.202...https://meetings.opendev.org/irclogs/#openstack-oslo/%23openstack-oslo.2022-09-02.log.html
Links to old material: - The old spec that we can work upon https://review.opendev.org/c/openstack/oslo-specs/+/692784 - Old driver implementation for above old spec https://review.opendev.org/c/openstack/oslo.messaging/+/680629 - Old asyncio planning https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio - Old asyncio executor in oslo.messaging https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor - Old messaging API mail thread https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html
Looking forward to talk to you all next monday!
Best regards Tobias
On 5 Sept 2022, at 12:48, Herve Beraud <hberaud@redhat.commailto:hberaud@redhat.com> wrote:
Le lun. 5 sept. 2022 à 10:00, Tobias Urdin <tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Thanks! It seems that we have some traction here to get started in a more structured manner.
I’m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic?
The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo
You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management.
I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec.
Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us!
Best regards Tobias
On 2 Sept 2022, at 10:35, Felix Hüttner <felix.huettner@mail.schwarzmailto:felix.huettner@mail.schwarz> wrote:
+1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin <mailto:tobias.urdin@binero.commailto:tobias.urdin@binero.com> a écrit : Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
On 30 Aug 2022, at 18:32, Kai Bojens <mailto:kb@kbojens.demailto:kb@kbojens.de> wrote:
Am 29.08.22 um 15:46 schrieb Tobias Urdin:
If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you.
Hi, I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack.
As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ.
This brings me to the most important question: Where do you run and test your code?
Greetings, Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarzhttps://www.datenschutz.schwarz/>.
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
Hi!
I just wanted to thank Tobias for all his work in this topic. He uses the plural form of verbs but I believe we could switch most to singular and it would be true nonetheless. Thank you again!
Kind regards, Radek
-yoctozepto
On Thu, 8 Dec 2022 at 22:02, Tobias Urdin tobias.urdin@binero.com wrote:
Hello,
I first would like to apologize for not keeping everybody in the loop but I’ve been very busy with a lot of work.
I just wanted to give a quick update on some potential progress.
First off, the Oslo meeting on the 19th of September ([1] log here) kicked us into a direction of how we could use the official nats.py python client [2] to talk to NATS as we quickly ruled out the nats-python client [3] as it’s pretty unmaintained and incomplete.
We did however get a working POC driver [4] (see patchset 14) with [3] that confirmed we could get a Devstack job working even though the driver missed a lot of critical functionality such as error handling, retries, TLS etc etc.
Since the nats.py client [2] is asyncio based we investigated a path forward that meant where we could utilize asyncio in the oslo.messaging library and expose an API up to projects consuming oslo.messaging.
We decided to do some POC patches into oslo.messaging and using the Blazar project as a testing ground [4]. We very quickly found ourselves digging into oslo.service to implement asyncio, checking SQLAlchemy for support, API frameworks would need asyncio support, moving from WSGI to an ASGI compatible server, duplicating code for supporting sync and async code paths and more.
We came to the conclussion that introducing a NATS oslo.messaging driver meant requiring us to implement asyncio across our ecosystem which would take an massive effort. Some good came out of it in form of a patch [5] further improving the consistency of the oslo.messaging API, we also gained a lot of insight in the future if we would like to start introducing asyncio functionality into oslo projects to support it for the future.
Now moving forward to today.
I’ve talked with the maintainer of nats.py and the company behind him to investigate if we can include a synchronous code path into that Python library to be used in a future revision of a oslo.messaging NATS driver. Hopefully we’ll have some more progress to report on that in the beginning of next year.
Feel free to reach out to me (here or on IRC, my nick is tobias-urdin) if you want to know more, have any questions or want to get involved in anything I’ve mentioned above!
Best regards Tobias
[1] https://meetings.opendev.org/meetings/oslo/2022/oslo.2022-09-19-15.12.log.tx... [2] https://github.com/nats-io/nats.py [3] https://github.com/Gr1N/nats-python [4] https://review.opendev.org/q/topic:asyncio-nats [5] https://review.opendev.org/c/openstack/oslo.messaging/+/862419
On 12 Sep 2022, at 09:05, Tobias Urdin tobias.urdin@binero.com wrote:
Hello,
Since I haven’t heard any objections we’ll move the meeting to the Oslo meeting on the 19th of September. See you there! [1]
[1] https://wiki.openstack.org/wiki/Meetings/Oslo
Best regards Tobias
On 8 Sept 2022, at 15:54, Herve Beraud hberaud@redhat.com wrote:
WFM
Le jeu. 8 sept. 2022 à 15:16, Tobias Urdin tobias.urdin@binero.com a écrit :
Hello,
I don’t have anything against moving to the 19th of September meeting if that’s OK with everybody else, I propose we do that.
Let’s see if we get some feedback against the proposed new date otherwise we’ll move it.
Best regards
On 8 Sept 2022, at 08:41, Radosław Piliszek radoslaw.piliszek@gmail.com wrote:
Hi Tobias et al,
That Monday I cannot attend due to other work commitments. Could we schedule it for the following week?
Cheers, Radek
On Tue, Sep 6, 2022, 18:33 Tobias Urdin tobias.urdin@binero.com wrote:
Great! I’ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material:
- Current POC code https://review.opendev.org/c/openstack/oslo.messaging/+/848338
- Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats
- Discussion on IRC on 2nd September about below links https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.202...
Links to old material:
- The old spec that we can work upon https://review.opendev.org/c/openstack/oslo-specs/+/692784
- Old driver implementation for above old spec https://review.opendev.org/c/openstack/oslo.messaging/+/680629
- Old asyncio planning https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio
- Old asyncio executor in oslo.messaging https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor
- Old messaging API mail thread https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html
Looking forward to talk to you all next monday!
Best regards Tobias
On 5 Sept 2022, at 12:48, Herve Beraud hberaud@redhat.com wrote:
Le lun. 5 sept. 2022 à 10:00, Tobias Urdin tobias.urdin@binero.com a écrit :
Thanks! It seems that we have some traction here to get started in a more structured manner.
I’m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic?
The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo
You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management.
I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec.
Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us!
Best regards Tobias
On 2 Sept 2022, at 10:35, Felix Hüttner felix.huettner@mail.schwarz wrote:
+1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc.
-- Felix Huettner
+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc...
Le jeu. 1 sept. 2022 à 15:50, Tobias Urdin mailto:tobias.urdin@binero.com a écrit : Hello Kai,
Great to hear that you're interested! I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first).
Best regards Tobias
> On 30 Aug 2022, at 18:32, Kai Bojens mailto:kb@kbojens.de wrote: > > Am 29.08.22 um 15:46 schrieb Tobias Urdin: > >> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >> reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you. > > Hi, > I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. > > As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. > > This brings me to the most important question: Where do you run and test your code? > > Greetings, > Kai
Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hierhttps://www.datenschutz.schwarz.
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
On 12/09/2022 09:05, Tobias Urdin wrote:
Hello,
Since I haven’t heard any objections we’ll move the meeting to the Oslo meeting on the 19th of September. See you there! [1]
Could you maybe give an update on the current state on adding NATS to oslo.messaging?
I know there was some positive exchange during an Oslo Meeting [1], but now all but the spec change [2] are abandoned? Is the work on the spec [3] still going then?
Regards
Christian
[1] https://meetings.opendev.org/meetings/oslo/2022/oslo.2022-09-19-15.12.log.tx... [2] https://review.opendev.org/q/topic:asyncio-nats [3] https://review.opendev.org/c/openstack/oslo-specs/+/692784
Hello Christian,
Sure, no problem I can give you a status update on the situation as of now!
The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
The investigation into introducing asyncio support in the ecosystem (oslo and then all separate projects) was a too massive effort.
Since then I’ve opened an issue [1] on the nats.py GitHub and some proof-of-concept patches [2] on introducing synchronous support in nats.py that we could then use in a driver.
The oslo.messaging driver patch [3] has Devstack passing when using [2] but it’s also more of a proof-of-concept patch that would need more work in itself.
Unfortunately I didn’t get any feedback from the company maintaining the nats.py library on supported developer time implemeting the sync client feature, I assume (my view) that they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus) in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time effort into it.
Best regards Tobias
[1] https://github.com/nats-io/nats.py/issues/462 [2] https://github.com/tobias-urdin/nats.py/commits/sync-client [3] https://review.opendev.org/c/openstack/oslo.messaging/+/878588
On 14 Jul 2023, at 09:37, Christian Rohmann christian.rohmann@inovex.de wrote:
On 12/09/2022 09:05, Tobias Urdin wrote:
Hello,
Since I haven’t heard any objections we’ll move the meeting to the Oslo meeting on the 19th of September. See you there! [1]
Could you maybe give an update on the current state on adding NATS to oslo.messaging?
I know there was some positive exchange during an Oslo Meeting [1], but now all but the spec change [2] are abandoned? Is the work on the spec [3] still going then?
Regards
Christian
[1] https://meetings.opendev.org/meetings/oslo/2022/oslo.2022-09-19-15.12.log.tx... [2] https://review.opendev.org/q/topic:asyncio-nats [3] https://review.opendev.org/c/openstack/oslo-specs/+/692784
Hey Tobias,
On 15/07/2023 16:27, Tobias Urdin wrote:
The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
The investigation into introducing asyncio support in the ecosystem (oslo and then all separate projects) was a too massive effort.
Since then I’ve opened an issue [1] on the nats.py GitHub and some proof-of-concept patches [2] on introducing synchronous support in nats.py that we could then use in a driver.
The oslo.messaging driver patch [3] has Devstack passing when using [2] but it’s also more of a proof-of-concept patch that would need more work in itself.
Unfortunately I didn’t get any feedback from the company maintaining the nats.py library on supported developer time implemeting the sync client feature, I assume (my view) that they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus) in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time effort into it.
Best regards Tobias
[1] https://github.com/nats-io/nats.py/issues/462 [2] https://github.com/tobias-urdin/nats.py/commits/sync-client [3] https://review.opendev.org/c/openstack/oslo.messaging/+/878588
Thanks for the rapid response and full overview of your NATS endeavors! I shall subscribe to your kindly linked issues. There currently also is a larger number of fixes for oslo.messaging via RabbitMQ incoming: a shift to quorum queues, fixed threading for heartbeats, adjusted timers and timeouts, .... Maybe they relieve a bit of the perceived pain with (oslo.messaging via) RabbitMQ.
To me it's not about having even more choices in messaging drivers (or coordination backends for that matter). All of them working slightly different, having different features and them each having +50 options to fiddle with all sorts of timers or adjust other settings. I'd rather have a single solution that is broadly used by most installs and that, proper setup, configuration and scaling provided, "just works". Even though there is an abstraction with oslo.(messaging|coordination), there always remain implications for the OpenStack components depending on which backend / driver one uses.
Anyways, thanks again for your response! Regards
Christian
On 7/15/23 16:27, Tobias Urdin wrote:
The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
Sorry to ask, but what's the problem with asyncio? Do we want something *not* async? If yes, why?
Unfortunately I didn’t get any feedback from the company maintaining the nats.py library on supported developer time implemeting the sync client feature, I assume (my view) that they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus) in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time effort into it.
Would it help if I was packaging NATS in Debian (and therefore, as a consequence, in Ubuntu)? By reading the go.mod, it feels like it has a reasonable amount of dependencies (though I didn't check for the indirect ones), so it feels like doable...
Cheers,
Thomas Goirand (zigo)
On Fri, 21 Jul 2023 at 09:03, Thomas Goirand zigo@debian.org wrote:
On 7/15/23 16:27, Tobias Urdin wrote:
The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
Sorry to ask, but what's the problem with asyncio? Do we want something *not* async? If yes, why?
Large swaths of OpenStack code are not ready for async. We want to take baby steps and get to some better place with tangible benefits.
Unfortunately I didn’t get any feedback from the company maintaining the nats.py library on supported developer time implemeting the sync client feature, I assume (my view) that they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus) in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time effort into it.
Would it help if I was packaging NATS in Debian (and therefore, as a consequence, in Ubuntu)? By reading the go.mod, it feels like it has a reasonable amount of dependencies (though I didn't check for the indirect ones), so it feels like doable...
NATS's preferred way of delivery is a single (!) binary offered by the upstream. I guess you could help considerably with minimum effort by repackaging it into a deb so that users going for apt hunting get the upstream NATS. Then it would only boil down to finally packaging the Python library that works well with both OpenStack and NATS but we don't have it yet.
Kind regards, Radek -yoctozepto
On Fri, 2023-07-21 at 11:59 +0200, Radosław Piliszek wrote:
On Fri, 21 Jul 2023 at 09:03, Thomas Goirand zigo@debian.org wrote:
On 7/15/23 16:27, Tobias Urdin wrote:
The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
Sorry to ask, but what's the problem with asyncio? Do we want something *not* async? If yes, why?
Large swaths of OpenStack code are not ready for async. We want to take baby steps and get to some better place with tangible benefits.
that not entirly correct. much of openstack is already async but we made a decision ot use eventlet as our async model many many years ago after we ported form twisted.
The problem is you cannot really mix eventlet code and asyncio safely in the python process. That means you cannot have the async nats lib used in nova,swift,cinder,neutron, glance and progrably other projects today.
i proposed one option a long time ago which is to take a privsep like approch where we spawn the oslo messaging driver into a sperate process and comunicate with it over a unix socket.
that would allow the oslo.messaging drvier to run with asynio and all the existing project to consume it unmodifed. a unix socket is just one way to hanel that of couse you coudl use any other ipc liek shared memory but the core logic for that exist in oslo.privsep in the form of the chanels it provids so we have prior art to work form.
but thats the main problem. most of openstack uses eventlets for implict async. eventlets and explict async are not safe to mix in the same process. and that is the bocker to the current python nats driver as far as i am aware.
Unfortunately I didn’t get any feedback from the company maintaining the nats.py library on supported developer time implemeting the sync client feature, I assume (my view) that they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus) in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time effort into it.
Would it help if I was packaging NATS in Debian (and therefore, as a consequence, in Ubuntu)? By reading the go.mod, it feels like it has a reasonable amount of dependencies (though I didn't check for the indirect ones), so it feels like doable...
NATS's preferred way of delivery is a single (!) binary offered by the upstream. I guess you could help considerably with minimum effort by repackaging it into a deb so that users going for apt hunting get the upstream NATS. Then it would only boil down to finally packaging the Python library that works well with both OpenStack and NATS but we don't have it yet.
Kind regards, Radek -yoctozepto
Thanks, Sean. Your summary is more elaborate. And I meant asyncio*, not async programming. Sorry for any confusion.
On Fri, 21 Jul 2023, 13:32 , smooney@redhat.com wrote:
On Fri, 2023-07-21 at 11:59 +0200, Radosław Piliszek wrote:
On Fri, 21 Jul 2023 at 09:03, Thomas Goirand zigo@debian.org wrote:
On 7/15/23 16:27, Tobias Urdin wrote:
The effort is mostly now to get/find a supported third-party Python
library that does not
use asyncio for usage in a oslo.messaging driver.
Sorry to ask, but what's the problem with asyncio? Do we want something *not* async? If yes, why?
Large swaths of OpenStack code are not ready for async. We want to take baby steps and get to some better place with tangible
benefits. that not entirly correct. much of openstack is already async but we made a decision ot use eventlet as our async model many many years ago after we ported form twisted.
The problem is you cannot really mix eventlet code and asyncio safely in the python process. That means you cannot have the async nats lib used in nova,swift,cinder,neutron, glance and progrably other projects today.
i proposed one option a long time ago which is to take a privsep like approch where we spawn the oslo messaging driver into a sperate process and comunicate with it over a unix socket.
that would allow the oslo.messaging drvier to run with asynio and all the existing project to consume it unmodifed. a unix socket is just one way to hanel that of couse you coudl use any other ipc liek shared memory but the core logic for that exist in oslo.privsep in the form of the chanels it provids so we have prior art to work form.
but thats the main problem. most of openstack uses eventlets for implict async. eventlets and explict async are not safe to mix in the same process. and that is the bocker to the current python nats driver as far as i am aware.
Unfortunately I didn’t get any feedback from the company maintaining
the nats.py library
on supported developer time implemeting the sync client feature, I
assume (my view) that
they didn’t like that we cannot guarantee that NATS would become a
core component (or used, or the primary bus)
in the ecosystem (since we don’t, and don’t want to for that matter,
force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top
priority and I don’t spend any full-time
effort into it.
Would it help if I was packaging NATS in Debian (and therefore, as a consequence, in Ubuntu)? By reading the go.mod, it feels like it has a reasonable amount of dependencies (though I didn't check for the indirect ones), so it feels like doable...
NATS's preferred way of delivery is a single (!) binary offered by the
upstream.
I guess you could help considerably with minimum effort by repackaging it into a deb so that users going for apt hunting get the upstream NATS. Then it would only boil down to finally packaging the Python library that works well with both OpenStack and NATS but we don't have it yet.
Kind regards, Radek -yoctozepto
On 7/21/23 11:59, Radosław Piliszek wrote:
On Fri, 21 Jul 2023 at 09:03, Thomas Goirand zigo@debian.org wrote:
Unfortunately I didn’t get any feedback from the company maintaining the nats.py library on supported developer time implemeting the sync client feature, I assume (my view) that they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus) in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time effort into it.
Would it help if I was packaging NATS in Debian (and therefore, as a consequence, in Ubuntu)? By reading the go.mod, it feels like it has a reasonable amount of dependencies (though I didn't check for the indirect ones), so it feels like doable...
NATS's preferred way of delivery is a single (!) binary offered by the upstream. I guess you could help considerably with minimum effort by repackaging it into a deb so that users going for apt hunting get the upstream NATS.
No way... :)
If I'm to do something, it wont be ugly bianry-only packaging. I was more thinking about doing a *real* packaging work, meaning packaging any missing Go dependency in Debian, and building from source. Otherwise, what value would this bring?
Then it would only boil down to finally packaging the Python library that works well with both OpenStack and NATS but we don't have it yet.
Considering the 400+ Python package I maintain for OpenStack in Debian, that'd be trivial 15 to 30 minutes work for me. :) Packaging a Go app the correct way, without breaking anything else in the whole Go stack in Debian is a way harder (ie: if something needs updating, then all reverse dependencies must be checked and possibly fixed...).
Cheers,
Thomas Goirand (zigo)
On 7/21/23 13:32, smooney@redhat.com wrote:
On Fri, 2023-07-21 at 11:59 +0200, Radosław Piliszek wrote:
On Fri, 21 Jul 2023 at 09:03, Thomas Goirand zigo@debian.org wrote:
On 7/15/23 16:27, Tobias Urdin wrote:
The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
Sorry to ask, but what's the problem with asyncio? Do we want something *not* async? If yes, why?
Large swaths of OpenStack code are not ready for async. We want to take baby steps and get to some better place with tangible benefits.
that not entirly correct. much of openstack is already async but we made a decision ot use eventlet as our async model many many years ago after we ported form twisted.
The problem is you cannot really mix eventlet code and asyncio safely in the python process. That means you cannot have the async nats lib used in nova,swift,cinder,neutron, glance and progrably other projects today.
i proposed one option a long time ago which is to take a privsep like approch where we spawn the oslo messaging driver into a sperate process and comunicate with it over a unix socket.
IRRC, back in 2014, at the Hongkong summit, there was a large consensus that Eventlet was a wrong choice. I can still remember Jay Pipes shouting "die Eventlet, die...". Fast forward nearly 10 years later, nothing has moved in that direction, and we're still stuck with that horrible hack. Why don't we just get rid of Eventlet and switch to asyncio instead? That'd be a *HUGE* improvement in terms of ... well many things ... less bugs, more maintainability, less breakage on each minor Python release, etc. That'd be a lot of work, I'm sure... At the same time, everyone would be happy to finally get rid of it.
Cheers,
Thomas Goirand (zigo)
On 12/8/22 22:55, Radosław Piliszek wrote:
Hi!
I just wanted to thank Tobias for all his work in this topic. He uses the plural form of verbs but I believe we could switch most to singular and it would be true nonetheless. Thank you again!
Kind regards, Radek
-yoctozepto
+1
Thank you Tobias!
Thomas
On Fri, 2023-07-21 at 15:40 +0200, Thomas Goirand wrote:
On 7/21/23 13:32, smooney@redhat.com wrote:
On Fri, 2023-07-21 at 11:59 +0200, Radosław Piliszek wrote:
On Fri, 21 Jul 2023 at 09:03, Thomas Goirand zigo@debian.org wrote:
On 7/15/23 16:27, Tobias Urdin wrote:
The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
Sorry to ask, but what's the problem with asyncio? Do we want something *not* async? If yes, why?
Large swaths of OpenStack code are not ready for async. We want to take baby steps and get to some better place with tangible benefits.
that not entirly correct. much of openstack is already async but we made a decision ot use eventlet as our async model many many years ago after we ported form twisted.
The problem is you cannot really mix eventlet code and asyncio safely in the python process. That means you cannot have the async nats lib used in nova,swift,cinder,neutron, glance and progrably other projects today.
i proposed one option a long time ago which is to take a privsep like approch where we spawn the oslo messaging driver into a sperate process and comunicate with it over a unix socket.
IRRC, back in 2014, at the Hongkong summit, there was a large consensus that Eventlet was a wrong choice. I can still remember Jay Pipes shouting "die Eventlet, die...". Fast forward nearly 10 years later, nothing has moved in that direction, and we're still stuck with that horrible hack. Why don't we just get rid of Eventlet and switch to asyncio instead? That'd be a *HUGE* improvement in terms of ... well many things ... less bugs, more maintainability, less breakage on each minor Python release, etc. That'd be a lot of work, I'm sure... At the same time, everyone would be happy to finally get rid of it.
we have consider that in the past and the reality is it would be a massive rewrite we considerd doing this when we were dicussiong moving to python3 and at various points since the problem is two fold. 1 we dont have contibutors able to work on this currently. 2 we dont have a good solution for how to do this incrementally.
in nova at least we did breicly consider tyring to add asyncio console-script entries points so that we couuld have an eventlet version and non eventlet version of each service to act as a bridge its somethign we could discuss again but makign such a change without introducing bugs or performance regressions would require a lot of careful engenieing work.
i would love to regarin the ablity ot run nova under a debugger and drop the dep on eventlet but i dont want to do that at the expense of stablity or perfromace for our customer.
some services liek the api and schduler would be relitivly simple to port. the compute agent and conductor on the other hand rely on the implict acync behavior to fucntion at all. nova-comptue with libvirt as at lest 3 while true loops to compunticate with rabbit, libvirt and privsep to name just one of the the issues tha towuld need to be resolved.
Cheers,
Thomas Goirand (zigo)
On Fri, 21 Jul 2023 at 15:37, Thomas Goirand zigo@debian.org wrote:
NATS's preferred way of delivery is a single (!) binary offered by the upstream. I guess you could help considerably with minimum effort by repackaging it into a deb so that users going for apt hunting get the upstream NATS.
No way... :)
If I'm to do something, it wont be ugly bianry-only packaging. I was more thinking about doing a *real* packaging work, meaning packaging any missing Go dependency in Debian, and building from source. Otherwise, what value would this bring?
apt-get install support with automatic signature validation, version vetting with testing against your OpenStack stack. Just less work for you. In the end you can create two packages: one directly from upstream and one built yourself - and then compare the two. So many possibilities!
Then it would only boil down to finally packaging the Python library that works well with both OpenStack and NATS but we don't have it yet.
Considering the 400+ Python package I maintain for OpenStack in Debian, that'd be trivial 15 to 30 minutes work for me. :)
That's lovely to hear (read)!
Packaging a Go app the correct way, without breaking anything else in the whole Go stack in Debian is a way harder (ie: if something needs updating, then all reverse dependencies must be checked and possibly fixed...).
The point with Go is that it has no dynamic linking... and this is *on purpose*. What you would be doing is repeating the compilation to produce the single static binary and package it. The upstream does this well - no reason to repeat unless building for fancy architectures. This also helps with ensuring everyone is bug-bug compatible if they run the same version - no need to check anything else. :D
On 2023-07-21 19:48:29 +0200 (+0200), Radosław Piliszek wrote: [...]
The point with Go is that it has no dynamic linking... and this is *on purpose*. What you would be doing is repeating the compilation to produce the single static binary and package it. The upstream does this well - no reason to repeat unless building for fancy architectures. This also helps with ensuring everyone is bug-bug compatible if they run the same version - no need to check anything else. :D
And while that concept certainly has its merits, it runs counter to the guiding principles of some software distributions which want to guarantee rebuildability with only tools and components present within that distribution, the ability to backport critical fixes to otherwise frozen contemporary versions of the software which may not fit with the upstream maintainers' release and support policies, the ability to prove reproducibility of builds, to be able to confirm that the binaries shipped were actually built from the source code upstream claimed, and so on.
Hello,
And just to iterate on this, just look at the code duplication (double the maintenance for an async and sync with eventlet code path). https://review.opendev.org/q/topic:asyncio-nats review.opendev.orghttps://review.opendev.org/q/topic:asyncio-nats [favicon.ico] https://review.opendev.org/q/topic:asyncio-nats
We’d need to duplicate oslo.service, oslo.messaging and all other common libraries being called in a asyncio code path, and not only that we’d need to consolidate everyone on a Pecan (REST API library) replacement that would support asyncio (a new oslo library?) and just imagine that migration and consolidation effort for multiple projects.
Even then we’d also need to port every single project to using it without regressions in performance.
It’s a crazy massive effort, but I fully agree that eventlet should have been gone long ago.
Best regards Tobias
On 21 Jul 2023, at 16:16, smooney@redhat.com wrote:
On Fri, 2023-07-21 at 15:40 +0200, Thomas Goirand wrote: On 7/21/23 13:32, smooney@redhat.com wrote: On Fri, 2023-07-21 at 11:59 +0200, Radosław Piliszek wrote: On Fri, 21 Jul 2023 at 09:03, Thomas Goirand zigo@debian.org wrote:
On 7/15/23 16:27, Tobias Urdin wrote: The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
Sorry to ask, but what's the problem with asyncio? Do we want something *not* async? If yes, why?
Large swaths of OpenStack code are not ready for async. We want to take baby steps and get to some better place with tangible benefits. that not entirly correct. much of openstack is already async but we made a decision ot use eventlet as our async model many many years ago after we ported form twisted.
The problem is you cannot really mix eventlet code and asyncio safely in the python process. That means you cannot have the async nats lib used in nova,swift,cinder,neutron, glance and progrably other projects today.
i proposed one option a long time ago which is to take a privsep like approch where we spawn the oslo messaging driver into a sperate process and comunicate with it over a unix socket.
IRRC, back in 2014, at the Hongkong summit, there was a large consensus that Eventlet was a wrong choice. I can still remember Jay Pipes shouting "die Eventlet, die...". Fast forward nearly 10 years later, nothing has moved in that direction, and we're still stuck with that horrible hack. Why don't we just get rid of Eventlet and switch to asyncio instead? That'd be a *HUGE* improvement in terms of ... well many things ... less bugs, more maintainability, less breakage on each minor Python release, etc. That'd be a lot of work, I'm sure... At the same time, everyone would be happy to finally get rid of it. we have consider that in the past and the reality is it would be a massive rewrite we considerd doing this when we were dicussiong moving to python3 and at various points since the problem is two fold. 1 we dont have contibutors able to work on this currently. 2 we dont have a good solution for how to do this incrementally.
in nova at least we did breicly consider tyring to add asyncio console-script entries points so that we couuld have an eventlet version and non eventlet version of each service to act as a bridge its somethign we could discuss again but makign such a change without introducing bugs or performance regressions would require a lot of careful engenieing work.
i would love to regarin the ablity ot run nova under a debugger and drop the dep on eventlet but i dont want to do that at the expense of stablity or perfromace for our customer.
some services liek the api and schduler would be relitivly simple to port. the compute agent and conductor on the other hand rely on the implict acync behavior to fucntion at all. nova-comptue with libvirt as at lest 3 while true loops to compunticate with rabbit, libvirt and privsep to name just one of the the issues tha towuld need to be resolved.
Cheers,
Thomas Goirand (zigo)
To add insult to injury, the services that would benefit the most (think nova) would require the most work. And, since the goal is to have NATS support and not remove eventlet (because there is like no force to do it now), it seems best to focus on porting NATS support to eventlet.
On Fri, 21 Jul 2023 at 23:31, Tobias Urdin tobias.urdin@binero.com wrote:
Hello,
And just to iterate on this, just look at the code duplication (double the maintenance for an async and sync with eventlet code path). review.opendev.org https://review.opendev.org/q/topic:asyncio-nats https://review.opendev.org/q/topic:asyncio-nats https://review.opendev.org/q/topic:asyncio-nats
We’d need to duplicate oslo.service, oslo.messaging and all other common libraries being called in a asyncio code path, and not only that we’d need to consolidate everyone on a Pecan (REST API library) replacement that would support asyncio (a new oslo library?) and just imagine that migration and consolidation effort for multiple projects.
Even then we’d also need to port every single project to using it without regressions in performance.
It’s a crazy massive effort, but I fully agree that eventlet should have been gone long ago.
Best regards Tobias
On 21 Jul 2023, at 16:16, smooney@redhat.com wrote:
On Fri, 2023-07-21 at 15:40 +0200, Thomas Goirand wrote:
On 7/21/23 13:32, smooney@redhat.com wrote:
On Fri, 2023-07-21 at 11:59 +0200, Radosław Piliszek wrote:
On Fri, 21 Jul 2023 at 09:03, Thomas Goirand zigo@debian.org wrote:
On 7/15/23 16:27, Tobias Urdin wrote:
The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
Sorry to ask, but what's the problem with asyncio? Do we want something *not* async? If yes, why?
Large swaths of OpenStack code are not ready for async. We want to take baby steps and get to some better place with tangible benefits.
that not entirly correct. much of openstack is already async but we made a decision ot use eventlet as our async model many many years ago after we ported form twisted.
The problem is you cannot really mix eventlet code and asyncio safely in the python process. That means you cannot have the async nats lib used in nova,swift,cinder,neutron, glance and progrably other projects today.
i proposed one option a long time ago which is to take a privsep like approch where we spawn the oslo messaging driver into a sperate process and comunicate with it over a unix socket.
IRRC, back in 2014, at the Hongkong summit, there was a large consensus that Eventlet was a wrong choice. I can still remember Jay Pipes shouting "die Eventlet, die...". Fast forward nearly 10 years later, nothing has moved in that direction, and we're still stuck with that horrible hack. Why don't we just get rid of Eventlet and switch to asyncio instead? That'd be a *HUGE* improvement in terms of ... well many things ... less bugs, more maintainability, less breakage on each minor Python release, etc. That'd be a lot of work, I'm sure... At the same time, everyone would be happy to finally get rid of it.
we have consider that in the past and the reality is it would be a massive rewrite we considerd doing this when we were dicussiong moving to python3 and at various points since the problem is two fold. 1 we dont have contibutors able to work on this currently. 2 we dont have a good solution for how to do this incrementally.
in nova at least we did breicly consider tyring to add asyncio console-script entries points so that we couuld have an eventlet version and non eventlet version of each service to act as a bridge its somethign we could discuss again but makign such a change without introducing bugs or performance regressions would require a lot of careful engenieing work.
i would love to regarin the ablity ot run nova under a debugger and drop the dep on eventlet but i dont want to do that at the expense of stablity or perfromace for our customer.
some services liek the api and schduler would be relitivly simple to port. the compute agent and conductor on the other hand rely on the implict acync behavior to fucntion at all. nova-comptue with libvirt as at lest 3 while true loops to compunticate with rabbit, libvirt and privsep to name just one of the the issues tha towuld need to be resolved.
Cheers,
Thomas Goirand (zigo)
On 7/21/23 16:16, smooney@redhat.com wrote:
we have consider that in the past and the reality is it would be a massive rewrite we considerd doing this when we were dicussiong moving to python3 and at various points since the problem is two fold. 1 we dont have contibutors able to work on this currently. 2 we dont have a good solution for how to do this incrementally.
in nova at least we did breicly consider tyring to add asyncio console-script entries points so that we couuld have an eventlet version and non eventlet version of each service to act as a bridge its somethign we could discuss again but makign such a change without introducing bugs or performance regressions would require a lot of careful engenieing work.
i would love to regarin the ablity ot run nova under a debugger and drop the dep on eventlet but i dont want to do that at the expense of stablity or perfromace for our customer.
some services liek the api and schduler would be relitivly simple to port. the compute agent and conductor on the other hand rely on the implict acync behavior to fucntion at all. nova-comptue with libvirt as at lest 3 while true loops to compunticate with rabbit, libvirt and privsep to name just one of the the issues tha towuld need to be resolved.
THere's probably another route. What if we were to somehow fork Eventlet, make it stop doing monkey patching, and reimplement its calls using asyncio? Do you think such approach would work? If so, it would have the huge advantage to implement the changes for all projects at once. Your thoughts?
Cheers,
Thomas Goirand (zigo)
On Sat, 22 Jul 2023 at 13:12, Thomas Goirand zigo@debian.org wrote:
On 7/21/23 16:16, smooney@redhat.com wrote:
we have consider that in the past and the reality is it would be a massive rewrite we considerd doing this when we were dicussiong moving to python3 and at various points since the problem is two fold. 1 we dont have contibutors able to work on this currently. 2 we dont have a good solution for how to do this incrementally.
in nova at least we did breicly consider tyring to add asyncio console-script entries points so that we couuld have an eventlet version and non eventlet version of each service to act as a bridge its somethign we could discuss again but makign such a change without introducing bugs or performance regressions would require a lot of careful engenieing work.
i would love to regarin the ablity ot run nova under a debugger and drop the dep on eventlet but i dont want to do that at the expense of stablity or perfromace for our customer.
some services liek the api and schduler would be relitivly simple to port. the compute agent and conductor on the other hand rely on the implict acync behavior to fucntion at all. nova-comptue with libvirt as at lest 3 while true loops to compunticate with rabbit, libvirt and privsep to name just one of the the issues tha towuld need to be resolved.
THere's probably another route. What if we were to somehow fork Eventlet, make it stop doing monkey patching, and reimplement its calls using asyncio? Do you think such approach would work? If so, it would have the huge advantage to implement the changes for all projects at once. Your thoughts?
zigo, the problem is that nova et al are relying on this monkey patching to work. So we are back to "rewrite it all so that it works in asyncio".
On 7/21/23 19:48, Radosław Piliszek wrote:
The point with Go is that it has no dynamic linking...
I would say: s/The point with/The main defect of/
What you would be doing is repeating the compilation to produce the single static binary and package it.
All what Jeremy replied, plus:
- having a version in Debian stable that we may *really* rely on, with bugs reported and fixed for months before the distro is released as stable. Not just the latest upstream release with the latest not-yet discovered bugs.
- A real auditable software supply chain, not just "curl | sudo bash" from the internet.
The upstream does this well - no reason to repeat unless building for fancy architectures.
yeah, there's that too! Having support for: - ppc64el - arm64 - risc-v - ... (you name it...) ...
That's one of the nice things with Debian! :)
This also helps with ensuring everyone is bug-bug compatible if they run the same version - no need to check anything else. :D
What helps is having everyone on the version from the distro, not everyone running the latest version from when they did their deployments (understand: everyone running something different).
Of course, YMMV. But these are the reasons I only deploy packaged software, and packaged the way we do in Debian. I understand why others prefer some other path, and deploy from upstream, it's not just what I like to do, and what I recommend against.
Cheers,
Thomas Goirand (zigo)
participants (8)
-
Christian Rohmann
-
Felix Hüttner
-
Herve Beraud
-
Jeremy Stanley
-
Radosław Piliszek
-
smooney＠redhat.com
-
Thomas Goirand
-
Tobias Urdin