Open Stack

On Mon, 2014-08-18 at 14:23 +0200, Thierry Carrez wrote:
> Clint Byrum wrote:
> > Here's why folk are questioning Ceilometer:
> > 
> > Nova is a set of tools to abstract virtualization implementations.
> > Neutron is a set of tools to abstract SDN/NFV implementations.
> > Cinder is a set of tools to abstract block-device implementations.
> > Trove is a set of tools to simplify consumption of existing databases.
> > Sahara is a set of tools to simplify Hadoop consumption.
> > Swift is a feature-complete implementation of object storage, none of
> > which existed when it was started.
> > Keystone supports all of the above, unifying their auth.
> > Horizon supports all of the above, unifying their GUI.
> > 
> > Ceilometer is a complete implementation of data collection and alerting.
> > There is no shortage of implementations that exist already.
> > 
> > I'm also core on two projects that are getting some push back these
> > days:
> > 
> > Heat is a complete implementation of orchestration. There are at least a
> > few of these already in existence, though not as many as their are data
> > collection and alerting systems.
> > 
> > TripleO is an attempt to deploy OpenStack using tools that OpenStack
> > provides. There are already quite a few other tools that _can_ deploy
> > OpenStack, so it stands to reason that people will question why we
> > don't just use those. It is my hope we'll push more into the "unifying
> > the implementations" space and withdraw a bit from the "implementing
> > stuff" space.
> > 
> > So, you see, people are happy to unify around a single abstraction, but
> > not so much around a brand new implementation of things that already
> > exist.
> 
> Right, most projects focus on providing abstraction above
> implementations, and that abstraction is where the real "domain
> expertise" of OpenStack should be (because no one else is going to do it
> for us). Every time we reinvent something, we are at larger risk because
> we are out of our common specialty, and we just may not be as good as
> the domain specialists. That doesn't mean we should never reinvent
> something, but we need to be damn sure it's a good idea before we do.
> It's sometimes less fun to piggyback on existing implementations, but if
> they exist that's probably what we should do.

It's certainly a valid angle to evaluate projects on, but it's also easy
to be overly reductive about it - e.g. that rather than "re-implement"
virtualization management, Nova should just be a thin abstraction over
vSphere, XenServer and oVirt.

To take that example, I don't think we as a project should be afraid of
having such discussions but it wouldn't be productive to frame that
conversation as "the sky is falling, Nova re-implements the wheel, we
should de-integrate it".

> While Ceilometer is far from alone in that space, what sets it apart is
> that even after it was blessed by the TC as "the one we should all
> converge on", we keep on seeing competing implementations for some (if
> not all) of its scope. Convergence did not happen, and without
> convergence we struggle in adoption. We need to understand why, and if
> this is fixable.

"Convergence did not happen" is a little unfair. It's certainly a busy
space, and things like Monasca and InfluxDB are new developments. I'm
impressed at how hard the Ceilometer team works to embrace such
developments and patiently talks through possibilities for convergence.
This attitude is something we should be applauding in an integrated
project.

Mark.