Open Stack

On 08/02/2013 08:38 AM, Doug Hellmann wrote:
> 
> 
> 
> On Thu, Aug 1, 2013 at 8:52 PM, Sandy Walsh <sandy.walsh at rackspace.com
> <mailto:sandy.walsh at rackspace.com>> wrote:
> 
> 
> 
>     On 08/01/2013 07:22 PM, Doug Hellmann wrote:
>     >
>     >
>     >
>     > On Thu, Aug 1, 2013 at 10:31 AM, Sandy Walsh
>     <sandy.walsh at rackspace.com <mailto:sandy.walsh at rackspace.com>
>     > <mailto:sandy.walsh at rackspace.com
>     <mailto:sandy.walsh at rackspace.com>>> wrote:
>     >
>     >     Hey y'all,
>     >
>     >     I've had a little thorn in my claw on this topic for a while
>     and thought
>     >     I'd ask the larger group.
>     >
>     >     I applaud the efforts of the people working on the alarming
>     additions to
>     >     Ceilometer, but I've got concerns that we're packaging things the
>     >     wrong way.
>     >
>     >     I fear we're making another Zenoss/Nagios with Ceilometer.
>     It's trying
>     >     to do too much.
>     >
>     >     The current trend in the monitoring work (#monitoringlove) is
>     to build
>     >     your own stack from a series of components. These components
>     take in
>     >     inputs, process them and spit out outputs.
>     >     Collectors/Transformers/Publishers. This is the model CM is
>     built on.
>     >
>     >     Making an all-singing-all-dancing monolithic monitoring
>     package is the
>     >     old way of building these tools. People want to use best-of-breed
>     >     components for their monitoring stack. I'd like to be able to use
>     >     reimann.io <http://reimann.io> <http://reimann.io> for my
>     stream manager, diamond for my
>     >     collector, logstash for
>     >     my parser, etc. Alarming should just be another consumer.
>     >
>     >     CM should do one thing well. Collect data from openstack,
>     store and
>     >     process them, and make them available to other systems via the
>     API or
>     >     publishers. That's all. It should understand these events
>     better than
>     >     any other product out there. It should be able to produce
>     meaningful
>     >     metrics/meters from these events.
>     >
>     >     Alarming should be yet another consumer of the data CM
>     produces. Done
>     >     right, the If-This-Then-That nature of the alarming tool could be
>     >     re-used by the orchestration team or perhaps even scheduling.
>     >     Intertwining it with CM is making the whole thing too complex
>     and rigid
>     >     (imho).
>     >
>     >     CM should be focused on extending our publishers and input
>     plug-ins.
>     >
>     >     I'd like to propose that alarming becomes its own project
>     outside of
>     >     Ceilometer. Or, at the very least, its own package, external
>     of the
>     >     Ceilometer code base. Perhaps it still lives under the CM
>     moniker, but
>     >     packaging-wise, I think it should live as a separate code base.
>     >
>     >
>     > It is currently implemented as a pair of daemons (one to monitor the
>     > alarm state, another to send the notifications). Both daemons use a
>     > ceilometer client to talk to the REST API to consume the sample
>     data or
>     > get the alarm details, as required. It looks like alarms are triggered
>     > by sending RPC cast message, and that those in turn trigger the
>     webhook
>     > invocation. That seems pretty loosely coupled, as far as the runtime
>     > goes. Granted, it's still in the main ceilometer code tree, but that
>     > doesn't say anything about how the distros will package it.
>     >
>     > I'll admit I haven't been closely involved in the development of this
>     > feature, so maybe my quick review of the code missed something that is
>     > bringing on this sentiment?
> 
>     No, you hit the nail on the head. It's nothing with the implementation,
>     it's purely with the packaging and having it co-exist within ceilometer.
>     Since it has its own services, uses Oslo, the CM client and operates via
>     the public API, it should be able to live outside the main CM codebase.
>     My concern is that it has a different mandate than CM (or the CM mandate
>     is too broad).
> 
>     What really brought it on for me was doing code reviews for CM and
>     hitting all this alarm stuff and thinking "this is mental context switch
>     from what CM does, it really doesn't belong here." (though I'm happy to
>     help out with the reviews)
> 
> 
> OK. I think we went back and forth for a while on where to put it, but
> at the time I think we really only discussed Heat and Ceilometer as
> options. (Eoghan or Angus, please correct me if I'm remembering those
> discussions incorrectly.) Now that we have "programs" instead of
> "projects" maybe it's more clear that a separate repository would be
> possible, although from a pragmatic standpoint leaving it where it is
> for the rest of this dev cycle seems reasonable.
> 
> Perhaps this is something to discuss at the summit?

Absolutely, no urgency here. I just wanted to get it in the ML to open
the conversation to a wider audience and have something to refer back to.

> Doug
>  
> 
> 
>     -S
> 
> 
>     >
>     > Doug
>     >
>     >
>     >
>     >     Please, change my view. :)
>     >
>     >     -S
>     >
>     >     Side note: I might even argue that the statistical features of
>     CM are
>     >     going a little too far. My only counter-argument is that
>     statistics are
>     >     the only way to prevent us from sending large amounts of data
>     over the
>     >     wire for post-processing. But that's a separate discussion.
>     >
>     >
>     >     _______________________________________________
>     >     OpenStack-dev mailing list
>     >     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     >     <mailto:OpenStack-dev at lists.openstack.org
>     <mailto: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
>     <mailto: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
>     <mailto: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
>