Open Stack

Hi Joonwon,

While it wouldn't necessarily be a showstopper to keep the two
git repos separate, it would probably make the release management
and "core privileges" aspects quite complex I suspect.

One potential compromise would be to maintain the original Synaps
repository for now, while forking off components piecemeal and
copying into the Ceilometer repo, following the kind of ordering
that Angus suggested earlier in this thread. The Ceilometer version
would be the focus for forward-looking development efforts, while
the original would be more like the stable/v1 branch (i.e. high 
priority bug fixes would be backported)

Once this transitioned implementation (say, Synaps v2) is production-
ready, you folks could switch over to deploying that instead.

Assuming you guys have the bandwidth for participation, we would look
at getting some Synaps contributors proposed to ceilometer-core
(giving +2 rights on code changes). This would allow you maintain
close oversight on the transitioned code.

How does that kind of approach sound?

Cheers,
Eoghan

----- Original Message -----
> 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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>