Open Stack

On 31/10/2022 15:07, Tobias Urdin wrote:
> Interesting topic, we use Redis because frankly we see that as the most logical choice
> due to the complexity of others.

Interesting now one's mileage varies :-)


> You might have seen my thread about investigating replacing RabbitMQ with NATS; our plan is to
> then also investigate getting Tooz and oslo.cache using the Jetstream Key-Value feature.

That sounds really interesting, I shall follow that discussion then.


If one tool, e.g. NATS in your case, could cover more than one 
communication use case, e.g. (async) messaging and distributed locking,
this would reduce the number of different components required to 
assemble a cloud, thus reducing the complexity. Even if there was more
than once instance of that software required.

As I was also arguing that adding more and more implementations and 
"ways" to do things, does neither help the operators nor the developers.
To me, software developers benefit from clear abstractions for such 
cross-cutting concerns as messaging or coordination. While e.g. tooz 
already
aims to be such an abstraction, when deploying OpenStack or operating a 
cloud things can look so vastly different.
No coordination at all, different drivers with different features and 
inherently different guarantees and behavior in case of problems.

Discussing broadly, and then agreeing not only on a common library and 
its interface, but also on an implementation to me is not inflexible, 
but makes
sense to keep the complexity manageable. It happened with MySQL/MariaDB 
as db engine and actually also with AMQP as messaging protocol 
(including it's paradigms).
It's progress to simply revisit such decisions and conventions over time.


Regards

Christian