Open Stack

> > Let's have a detailed discussion about the technicalities of
> > managing
> > the two codebases, issue tracking, task prioritization etc.
> 
> Ok, so lets figure out how were going to do this.
> 
> First question is how to approach managing the two codebases.
> 
> My instinct to merge the Synaps code into the Ceilo git repo,
> re-packaging as ceilometer.synaps. Thoughts?
> 
> Secondly, in terms of issue tracking, the number of bugs
> filed against https://launchpad.net/synaps is small, so we
> could easily do a manual migration to a single consolidated
> tracker under https://launchpad.net/ceilometer . Thoughts?
> 
> Finally in terms of prioritizing tasks, here's my laundry
> list that I'm planning to translate to blueprints once the
> initial transitions are done. Any further input would be
> welcome.
> 
> - clean up the long & awkward dependency chain and allow
> Synaps be sparked up optionally within devstack
> 
> - beef up test coverage, which is currently low and has a
> strong functional as opposed to unittest orientation
> 
> - push the Cassandra usage behind a storage abstraction,
> to allow for pluggable stores
> 
> - add a native API, alongside the AWS CloudWatch API
> (capturing some of the novel aspects of Synaps,
> e.g. the concept of overlapping eval periods)
> 
> - decouple metric ingestion and alarm evaluation from
> storm (currently embedded in the storm bolts)
> 
> - support alternative non-storm (well, non-Java-oriented)
> distributed computation frameworks
> 
> - switch to a periodic alarm threshold evaluation model
> (as evaluation on metric ingestion is prone to
> false positives when outliers report first)
> 
> 
> 
> Some of that sounds like it would be a good bit of work. 

Yes, some of it is quite forward looking.

> How much of it do you think should be done before the code
> is brought into the ceilometer repository vs. after?

I'd be in favor of bringing it in as early as possible and
then doing the transition work gradually.  

Cheers,
Eoghan