Excerpts from Chris Friesen's message of 2015-10-08 23:52:41 -0700: > On 10/08/2015 01:37 AM, Clint Byrum wrote: > > Excerpts from Maish Saidel-Keesing's message of 2015-10-08 00:14:55 -0700: > >> Forgive the top-post. > >> > >> Cross-posting to openstack-operators for their feedback as well. > >> > >> Ed the work seems very promising, and I am interested to see how this > >> evolves. > >> > >> With my operator hat on I have one piece of feedback. > >> > >> By adding in a new Database solution (Cassandra) we are now up to three > >> different database solutions in use in OpenStack > >> > >> MySQL (practically everything) > >> MongoDB (Ceilometer) > >> Cassandra. > >> > >> Not to mention two different message queues > >> Kafka (Monasca) > >> RabbitMQ (everything else) > >> > >> Operational overhead has a cost - maintaining 3 different database > >> tools, backing them up, providing HA, etc. has operational cost. > >> > >> This is not to say that this cannot be overseen, but it should be taken > >> into consideration. > >> > >> And *if* they can be consolidated into an agreed solution across the > >> whole of OpenStack - that would be highly beneficial (IMHO). > >> > > > > Just because they both say they're databases, doesn't mean they're even > > remotely similar. > > True, but the fact remains that it means operators (and developers) would > have > to become familiar with the quirks and problems of yet another piece of > technology. >
Indeed! And we can get really opinionated here now that we have some experience I think. Personally, I'd rather become familiar with the quirks and problems of Cassandra, than try to become familiar with the quirks and problems of OpenStack's invented complex workarounds for high scale state management <cough>cells</cough>. So I agree with the statement that the cost of adding a technology should be weighed. However, the cost of inventing a workaround should be weighed with the same scale. Complex workarounds will, in most cases, weigh much more than adopting a well known and proven technology that is aimed at what turns out to be a common problem set. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev