Open Stack

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