Open Stack

Hi Everyone,

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.

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:

1.  Relying on oslo messaging (which is RPC based) simply won't scale when 
you have a high volume monitoring requirement.
2.  Having to query the database first for doing triggers breaks when the 
database gets big.
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.

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. 

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.

Thanks,

Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  btopol at us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Clint Byrum <clint at fewbar.com>
To:     openstack-dev <openstack-dev at lists.openstack.org>, 
Date:   08/21/2014 04:13 PM
Subject:        Re: [openstack-dev] [all] The future of the integrated 
release



Excerpts from David Kranz's message of 2014-08-21 12:45:05 -0700:
> On 08/21/2014 02:39 PM, gordon chung wrote:
> > > The point I've been making is
> > > that by the TC continuing to bless only the Ceilometer project as 
the
> > > OpenStack Way of Metering, I think we do a disservice to our users 
by
> > > picking a winner in a space that is clearly still unsettled.
> >
> > can we avoid using the word 'blessed' -- it's extremely vague and 
> > seems controversial. from what i know, no one is being told project 
> > x's services are the be all end all and based on experience, companies 

> > (should) know this. i've worked with other alternatives even though i 
> > contribute to ceilometer.
> > > Totally agree with Jay here, I know people who gave up on trying to
> > > get any official project around deployment because they were told 
they
> > > had to do it under the TripleO umbrella
> > from the pov of a project that seems to be brought up constantly and 
> > maybe it's my naivety, i don't really understand the fascination with 
> > branding and the stigma people have placed on 
> > non-'openstack'/stackforge projects. it can't be a legal thing because 

> > i've gone through that potential mess. also, it's just as easy to 
> > contribute to 'non-openstack' projects as 'openstack' projects (even 
> > easier if we're honest).
> Yes, we should be honest. The "even easier" part is what Sandy cited as 
> the primary motivation for pursuing stacktach instead of ceilometer.
> 
> I think we need to consider the difference between why OpenStack wants 
> to bless a project, and why a project might want to be blessed by 
> OpenStack. Many folks believe that for OpenStack to be successful it 
> needs to present itself as a stack that can be tested and deployed, not 
> a sack of parts that only the most extremely clever people can manage to 

> assemble into an actual cloud. In order to have such a stack, some code 
> (or, alternatively, dare I say API...) needs to be blessed. Reasonable 
> debates will continue about which pieces are essential to this stack, 
> and which should be left to deployers, but metering was seen as such a 
> component and therefore something needed to be blessed. The hope was 
> that every one would jump on that and make it great but it seems that 
> didn't quite happen (at least yet).
> 
> Though Open Source has many advantages over proprietary development, the 

> ability to choose a direction and marshal resources for efficient 
> delivery is the biggest advantage of proprietary development like what 
> AWS does. The TC process of blessing is, IMO, an attempt to compensate 
> for that in an OpenSource project. Of course if the wrong code is 
> blessed, the negative  impact can be significant. Blessing APIs would be 


Hm, I wonder if the only difference there is when AWS blesses the wrong
thing, they evaluate the business impact, and respond by going in a
different direction, all behind closed doors. The shame is limited to
that inner circle.

Here, with full transparency, calling something "the wrong thing" is
pretty much public humiliation for the team involved.

So it stands to reason that we shouldn't call something "the right
thing" if we aren't comfortable with the potential public shaming.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140821/2a94a548/attachment.html>