[openstack-dev] [Openstack-operators] Scheduler proposal
clint at fewbar.com
Fri Oct 9 17:29:33 UTC 2015
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.
More information about the OpenStack-dev