Open Stack

Dear all,
Is it possible to maintain a separate source repository with a unified issue tracker? It would be better for us now as we're deploying Synaps in our private cloud. 
With its own git repository, we can do more work with you guys and the overall community can get more benefit, in my opinion.

Thanks,
Joonwon Lee



------- Original Message ------- 
Sender : Angus Salkeld <asalkeld at redhat.com> asalkeld at redhat.com
Date : 2012-12-06 10:34 (GMT 09:00)
Title : Re: [openstack-dev] [ceilometer][synaps] Ceilometer and Synaps joining
 forces

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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev