[openstack-dev] [ceilometer][synaps] Ceilometer and Synaps joining forces

Monty Taylor mordred at inaugust.com
Wed Dec 5 21:05:32 UTC 2012



On 12/05/2012 11:39 AM, Doug Hellmann wrote:
> 
> 
> On Wed, Dec 5, 2012 at 12:38 PM, Eoghan Glynn <eglynn at redhat.com
> <mailto:eglynn at redhat.com>> wrote:
> 
> 
> 
>     > 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

Very much ++

>      - 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. How much of it
> do you think should be done before the code is brought into the
> ceilometer repository vs. after?
> 
> Doug
>  
> 
> 
>     Cheers,
>     Eoghan
> 
>     _______________________________________________
>     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
> 



More information about the OpenStack-dev mailing list