[openstack-dev] [ceilometer][synaps] Ceilometer and Synaps joining forces
Angus Salkeld
asalkeld at redhat.com
Thu Dec 6 01:34:51 UTC 2012
On 05/12/12 12:38 -0500, Eoghan Glynn 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?
how about just put the functionally where we would normally
put it:
bins
bin/ceilometer-api-cw
bin/ceilometer-(what ever makes sense)
the API
ceilometer/api/cw/
all the alarm stuff
ceilometer/alarm/
db code (I know it's got a different schema now, but maybe
in time we can move to one schema to make use of the
other db drivers?)
storage/impl_cass.py
etc...
Shouldn't be tricky to move the "bits" around.
-Angus
>
>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
Yea, before we do any major (re-)work we need to do this.
>
> - push the Cassandra usage behind a storage abstraction,
> to allow for pluggable stores
Hopefully we can move to a single schema so metering can gain
Cassandra and monitoring can gain mongo & sql
>
> - 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)
+100
> - 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)
>
>Cheers,
>Eoghan
>
>_______________________________________________
>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