On 08/02/2013 08:38 AM, Doug Hellmann wrote: > > > > On Thu, Aug 1, 2013 at 8:52 PM, Sandy Walsh <sandy.wa...@rackspace.com > <mailto:sandy.wa...@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.wa...@rackspace.com <mailto:sandy.wa...@rackspace.com> > > <mailto:sandy.wa...@rackspace.com > <mailto:sandy.wa...@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@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > > <mailto:OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
