Open Stack

On 18 August 2014 09:32, Clint Byrum <clint at 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
discussion).

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

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud