Open Stack

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.

Excerpts from Nadya Privalova's message of 2014-08-17 11:11:34 -0700:
> Hello all,
> 
> As a Ceilometer's core, I'd like to add my 0.02$.
> 
> During previous discussions it was mentioned several projects which were
> started or continue to be developed after Ceilometer became integrated. The
> main question I'm thinking of is why it was impossible to contribute into
> existing integrated project? Is it because of Ceilometer's architecture,
> the team or there are some other (maybe political) reasons? I think it's a
> very sad situation when we have 3-4 Ceilometer-like projects from different
> companies instead of the only one that satisfies everybody. (We don't see
> it in other projects. Though, maybe there are several Novas os Neutrons on
> StackForge and I don't know about it...)
> Of course, sometimes it's much easier to start the project from scratch.
> But there should be strong reasons for doing this if we are talking about
> integrated project.
> IMHO the idea, the role is the most important thing when we are talking
> about integrated project. And if Ceilometer's role is really needed (and I
> think it is) then we should improve existing implementation, "merge" all
> needs into the one project and the result will be still Ceilometer.
> 
> Thanks,
> Nadya
> 
> On Fri, Aug 15, 2014 at 12:41 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> 
> >
> >
> >
> > On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann <doug at doughellmann.com>
> > wrote:
> >
> >>
> >> On Aug 13, 2014, at 3:05 PM, Eoghan Glynn <eglynn at redhat.com> wrote:
> >>
> >> >
> >> >>> At the end of the day, that's probably going to mean saying No to more
> >> >>> things. Everytime I turn around everyone wants the TC to say No to
> >> >>> things, just not to their particular thing. :) Which is human nature.
> >> >>> But I think if we don't start saying No to more things we're going to
> >> >>> end up with a pile of mud that no one is happy with.
> >> >>
> >> >> That we're being so abstract about all of this is frustrating. I get
> >> >> that no-one wants to start a flamewar, but can someone be concrete
> >> about
> >> >> what they feel we should say 'no' to but are likely to say 'yes' to?
> >> >>
> >> >>
> >> >> I'll bite, but please note this is a strawman.
> >> >>
> >> >> No:
> >> >> * Accepting any more projects into incubation until we are comfortable
> >> with
> >> >> the state of things again
> >> >> * Marconi
> >> >> * Ceilometer
> >> >
> >> > Well -1 to that, obviously, from me.
> >> >
> >> > Ceilometer is on track to fully execute on the gap analysis coverage
> >> > plan agreed with the TC at the outset of this cycle, and has an active
> >> > plan in progress to address architectural debt.
> >>
> >> Yes, there seems to be an attitude among several people in the community
> >> that the Ceilometer team denies that there are issues and refuses to work
> >> on them. Neither of those things is the case from our perspective.
> >>
> >
> > Totally agree.
> >
> >
> >>
> >> Can you be more specific about the shortcomings you see in the project
> >> that aren’t being addressed?
> >>
> >
> >
> > Once again, this is just a strawman.
> >
> > I'm just not sure OpenStack has 'blessed' the best solution out there.
> >
> >
> > https://wiki.openstack.org/wiki/Ceilometer/Graduation#Why_we_think_we.27re_ready
> >
> > "
> >
> >    - Successfully passed the challenge of being adopted by 3 related
> >    projects which have agreed to join or use ceilometer:
> >       - Synaps
> >       - Healthnmon
> >       - StackTach
> >       <https://wiki.openstack.org/w/index.php?title=StackTach&action=edit&redlink=1>
> >       "
> >
> >
> > Stacktach seems to still be under active development (
> > http://git.openstack.org/cgit/stackforge/stacktach/log/), is used by
> > rackspace in production and from everything I hear is more mature then
> > ceilometer.
> >
> >
> >>
> >> >
> >> >> Divert all cross project efforts from the following projects so we can
> >> focus
> >> >> our cross project resources. Once we are in a bitter place we can
> >> expand our
> >> >> cross project resources to cover these again. This doesn't mean
> >> removing
> >> >> anything.
> >> >> * Sahara
> >> >> * Trove
> >> >> * Tripleo
> >> >
> >> > You write as if cross-project efforts are both of fixed size and
> >> > amenable to centralized command & control.
> >> >
> >> > Neither of which is actually the case, IMO.
> >> >
> >> > Additional cross-project resources can be ponied up by the large
> >> > contributor companies, and existing cross-project resources are not
> >> > necessarily divertable on command.
> >>
> >
> > Sure additional cross-project resources can and need to be ponied up, but
> > I am doubtful that will be enough.
> >
> >
> >>
> >> What “cross-project efforts” are we talking about? The liaison program in
> >> Oslo has been a qualified success so far. Would it make sense to extend
> >> that to other programs and say that each project needs at least one
> >> designated QA, Infra, Doc, etc. contact?
> >>
> >> Doug
> >>
> >> >
> >> >> Yes:
> >> >> * All integrated projects that are not listed above
> >> >
> >> > And what of the other pending graduation request?
> >> >
> >> > Cheers,
> >> > Eoghan
> >>
> >> >
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >