[openstack-dev] [Openstack-operators] Scheduler proposal

Clint Byrum 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 mailing list