Open Stack

On Thu, Aug 1, 2013 at 8:52 PM, Sandy Walsh <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>> 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> 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?

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>
> >     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130802/b91729f2/attachment.html>