On 18 August 2014 09:32, Clint Byrum <cl...@fewbar.com> wrote:

I can see your perspective but I don't think its internally consistent...

> Here's why folk are questioning Ceilometer:
> Nova is a set of tools to abstract virtualization implementations.

With a big chunk of local things - local image storage (now in
glance), scheduling, rebalancing, ACLs and quotas. Other
implementations that abstract over VM's at various layers already
existed when Nova started - some bad ( some very bad!) and others
actually quite ok.

> Neutron is a set of tools to abstract SDN/NFV implementations.

And implements a DHCP service, DNS service, overlay networking : its
much more than an abstraction-over-other-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.

Swift was started in 2009; Eucalyptus goes back to 2007, with Walrus
part of that - I haven't checked precise dates, but I'm pretty sure
that it existed and was usable by the start of 2009. There may well be
other object storage implementations too - I simply haven't checked.

> Keystone supports all of the above, unifying their auth.

And implementing an IdP (which I know they want to stop doing ;)). And
in fact lots of OpenStack projects, for various reasons support *not*
using Keystone (something that bugs me, but thats a different

> 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.

If the other examples we had were a lot purer, this explanation would
make sense. I think there's more to it than that though :).

What exactly, I don't know, but its just too easy an answer, and one
that doesn't stand up to non-trivial examination :(.

I'd like to see more unification of implementations in TripleO - but I
still believe our basic principle of using OpenStack technologies that
already exist in preference to third party ones is still sound, and
offers substantial dogfood and virtuous circle benefits.


Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

OpenStack-dev mailing list

Reply via email to