Difference between revisions of "Ceilometer/Graduation"
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
== Why we think we're ready == | == Why we think we're ready == | ||
| − | + | * Deployed and in use at many sites | |
| + | ** [[DreamHost]] | ||
| + | ** eNovance | ||
| + | ** [[CloudWatt]] | ||
| + | ** AT&T | ||
| + | ** etc... | ||
| + | * Robust multi purpose architecture recently extended to support multiple publishing channels, thus allowing ceilometer to become a metrics source for other tools appart from metering | ||
| + | * Successfully passed the adoption challenge of 2 related projects | ||
| + | ** Synaps | ||
| + | ** Healthnmon | ||
| + | * Delivered Folsom within 2 weeks of release, prior to incubation | ||
| + | * Successfully delivered the G2 milestone with the project | ||
| + | * Good integration with all core projects now, including swift | ||
== Is our architecture stable? == | == Is our architecture stable? == | ||
| − | + | Even though discussion with healthnmon and sandywalsh have been deep and convoluted, we still beleive that they have not endangered the founding of ceilometer architecture. The main challenge was to explain the reasoning behind our choices which, while different in their approach of the problem of collecting metrics from other projects, proved sound enough that we now have, without changing the fundamentals of our architecture a solution which: | |
| + | * allows lean collection of metric from supporting project that send events on the Oslo bus | ||
| + | * permits regular fetching of data via a pull mechanism for non event generating projects (ie SWIFT) | ||
| + | * allows more intrusive data collection for non support project via an optional agent mechanism | ||
| + | The same metrics can then be retrived at different intervals and republished to multiple destinations based on a very slick configuration mechanism, thus allowing seemless integration of multiple projects around ceilometer without forcing the use of a single database and API. | ||
Revision as of 21:56, 11 February 2013
Why we think we're ready
- Deployed and in use at many sites
- Robust multi purpose architecture recently extended to support multiple publishing channels, thus allowing ceilometer to become a metrics source for other tools appart from metering
- Successfully passed the adoption challenge of 2 related projects
- Synaps
- Healthnmon
- Delivered Folsom within 2 weeks of release, prior to incubation
- Successfully delivered the G2 milestone with the project
- Good integration with all core projects now, including swift
Is our architecture stable?
Even though discussion with healthnmon and sandywalsh have been deep and convoluted, we still beleive that they have not endangered the founding of ceilometer architecture. The main challenge was to explain the reasoning behind our choices which, while different in their approach of the problem of collecting metrics from other projects, proved sound enough that we now have, without changing the fundamentals of our architecture a solution which:
- allows lean collection of metric from supporting project that send events on the Oslo bus
- permits regular fetching of data via a pull mechanism for non event generating projects (ie SWIFT)
- allows more intrusive data collection for non support project via an optional agent mechanism
The same metrics can then be retrived at different intervals and republished to multiple destinations based on a very slick configuration mechanism, thus allowing seemless integration of multiple projects around ceilometer without forcing the use of a single database and API.
