<br><br><div class="gmail_quote">On Wed, Dec 5, 2012 at 12:38 PM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
> Let's have a detailed discussion about the technicalities of managing<br>
> the two codebases, issue tracking, task prioritization etc.<br>
<br>
</div>Ok, so lets figure out how were going to do this.<br>
<br>
First question is how to approach managing the two codebases.<br>
<br>
My instinct to merge the Synaps code into the Ceilo git repo,<br>
re-packaging as ceilometer.synaps. Thoughts?<br>
<br>
Secondly, in terms of issue tracking, the number of bugs<br>
filed against <a href="https://launchpad.net/synaps" target="_blank">https://launchpad.net/synaps</a> is small, so we<br>
could easily do a manual migration to a single consolidated<br>
tracker under <a href="https://launchpad.net/ceilometer" target="_blank">https://launchpad.net/ceilometer</a>. Thoughts?<br>
<br>
Finally in terms of prioritizing tasks, here's my laundry<br>
list that I'm planning to translate to blueprints once the<br>
initial transitions are done. Any further input would be<br>
welcome.<br>
<br>
- clean up the long & awkward dependency chain and allow<br>
Synaps be sparked up optionally within devstack<br>
<br>
- beef up test coverage, which is currently low and has a<br>
strong functional as opposed to unittest orientation<br>
<br>
- push the Cassandra usage behind a storage abstraction,<br>
to allow for pluggable stores<br>
<br>
- add a native API, alongside the AWS CloudWatch API<br>
(capturing some of the novel aspects of Synaps,<br>
e.g. the concept of overlapping eval periods)<br>
<br>
- decouple metric ingestion and alarm evaluation from<br>
storm (currently embedded in the storm bolts)<br>
<br>
- support alternative non-storm (well, non-Java-oriented)<br>
distributed computation frameworks<br>
<br>
- switch to a periodic alarm threshold evaluation model<br>
(as evaluation on metric ingestion is prone to<br>
false positives when outliers report first)<br></blockquote><div><br></div><div>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?</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Eoghan<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>