<font size=2 face="sans-serif">Hi Everyone,</font>
<br>
<br><font size=2 face="sans-serif">I have seen a ton of notes on this topic.
Many of us have a lot invested in Ceilometer and want it to succeed.
I don't want to focus on whether Ceilometer should be in the integrated
release or not. To me the bigger issue is that if Ceilometer views itself
as wanting to be a monitoring infrastructure for OpenStack it needs
to be able to scale. If it is a tool that can handle high volume
monitoring loads it will attract new contributors because more folks will
use it and will want to contribute to it.</font>
<br>
<br><font size=2 face="sans-serif">I am happy to leave it to the Ceilometer
team to figure out a redesign that enables them to scale. I have
been asked in the past to be more concrete and make some suggested improvements.
Here is a very short list:</font>
<br>
<br><font size=2 face="sans-serif">1. Relying on oslo messaging (which
is RPC based) simply won't scale when you have a high volume monitoring
requirement.</font>
<br><font size=2 face="sans-serif">2. Having to query the database
first for doing triggers breaks when the database gets big.</font>
<br><font size=2 face="sans-serif">3. There needs to be a way
to keep the database from getting too large. Usually this means being able
to move data from the database to a data warehouse and having the data
warehouse available to handle data querying loads.</font>
<br>
<br><font size=2 face="sans-serif">Whenever the Ceilometer team feels they
can scale significantly more than they do now I'm sure folks will take
another look at it. When given a choice many of us want to reuse
an Open Source option that meets our needs whether it has the fancy branding
or not. In the near term many of us have to provide a monitoring
solution. And many of us have folks on staff that have significant
high volume monitoring experience and those folks feel there are some Open
Source monitoring components that are a better foundation for providing
high volume monitoring. </font>
<br>
<br><font size=2 face="sans-serif">So in summary I do hope there will be
less focus on whether Ceilometer has fancy status or not and instead more
focus on an open and frank dialogue on what can be done for Ceilometer
to achieve its goal of being able to meet high volume monitoring requirements.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Brad</font>
<br><font size=2 face="sans-serif"><br>
<br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet: btopol@us.ibm.com<br>
Assistant: Kendra Witherspoon (919) 254-0680</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Clint Byrum <clint@fewbar.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">openstack-dev <openstack-dev@lists.openstack.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">08/21/2014 04:13 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[all] The future of the integrated release</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Excerpts from David Kranz's message of 2014-08-21
12:45:05 -0700:<br>
> On 08/21/2014 02:39 PM, gordon chung wrote:<br>
> > > The point I've been making is<br>
> > > that by the TC continuing to bless only the Ceilometer project
as the<br>
> > > OpenStack Way of Metering, I think we do a disservice to
our users by<br>
> > > picking a winner in a space that is clearly still unsettled.<br>
> ><br>
> > can we avoid using the word 'blessed' -- it's extremely vague
and <br>
> > seems controversial. from what i know, no one is being told project
<br>
> > x's services are the be all end all and based on experience,
companies <br>
> > (should) know this. i've worked with other alternatives even
though i <br>
> > contribute to ceilometer.<br>
> > > Totally agree with Jay here, I know people who gave up on
trying to<br>
> > > get any official project around deployment because they
were told they<br>
> > > had to do it under the TripleO umbrella<br>
> > from the pov of a project that seems to be brought up constantly
and <br>
> > maybe it's my naivety, i don't really understand the fascination
with <br>
> > branding and the stigma people have placed on <br>
> > non-'openstack'/stackforge projects. it can't be a legal thing
because <br>
> > i've gone through that potential mess. also, it's just as easy
to <br>
> > contribute to 'non-openstack' projects as 'openstack' projects
(even <br>
> > easier if we're honest).<br>
> Yes, we should be honest. The "even easier" part is what
Sandy cited as <br>
> the primary motivation for pursuing stacktach instead of ceilometer.<br>
> <br>
> I think we need to consider the difference between why OpenStack wants
<br>
> to bless a project, and why a project might want to be blessed by
<br>
> OpenStack. Many folks believe that for OpenStack to be successful
it <br>
> needs to present itself as a stack that can be tested and deployed,
not <br>
> a sack of parts that only the most extremely clever people can manage
to <br>
> assemble into an actual cloud. In order to have such a stack, some
code <br>
> (or, alternatively, dare I say API...) needs to be blessed. Reasonable
<br>
> debates will continue about which pieces are essential to this stack,
<br>
> and which should be left to deployers, but metering was seen as such
a <br>
> component and therefore something needed to be blessed. The hope was
<br>
> that every one would jump on that and make it great but it seems that
<br>
> didn't quite happen (at least yet).<br>
> <br>
> Though Open Source has many advantages over proprietary development,
the <br>
> ability to choose a direction and marshal resources for efficient
<br>
> delivery is the biggest advantage of proprietary development like
what <br>
> AWS does. The TC process of blessing is, IMO, an attempt to compensate
<br>
> for that in an OpenSource project. Of course if the wrong code is
<br>
> blessed, the negative impact can be significant. Blessing APIs
would be <br>
<br>
Hm, I wonder if the only difference there is when AWS blesses the wrong<br>
thing, they evaluate the business impact, and respond by going in a<br>
different direction, all behind closed doors. The shame is limited to<br>
that inner circle.<br>
<br>
Here, with full transparency, calling something "the wrong thing"
is<br>
pretty much public humiliation for the team involved.<br>
<br>
So it stands to reason that we shouldn't call something "the right<br>
thing" if we aren't comfortable with the potential public shaming.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>