Difference between revisions of "Ceilometer/Graduation"
| Line 18: | Line 18: | ||
== Is our architecture stable? == | == Is our architecture stable? == | ||
Discussion with Healthnmon and sandywalsh have been deep and involved. We believe their suggestions are still obtainable with only slight modifications to Ceilometer architecture without changing the fundamentals. 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, provides a solution which: | Discussion with Healthnmon and sandywalsh have been deep and involved. We believe their suggestions are still obtainable with only slight modifications to Ceilometer architecture without changing the fundamentals. 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, provides a solution which: | ||
| − | * allows lean collection of | + | * allows lean collection of metrics from supporting projects that send events on the Oslo bus |
| − | * permits regular fetching of data via a pull mechanism for non | + | * permits regular fetching of data via a pull mechanism for non-notification-generating projects (i.e. Swift) |
| − | * allows more intrusive data collection for non | + | * allows more intrusive data collection for non-supported projects via an optional agent mechanism |
| − | The same | + | The same measurements can then be retrieved at different intervals and republished to multiple destinations though a YAML-based configuration mechanism, thus allowing seamless integration of multiple projects around Ceilometer without forcing the use of a single database and API. |
There are still some aspects of the architecture that are still emerging (such as database schemas for metadata/rich data and aggregation) and all groups have committed to working on a mutually acceptable solution. | There are still some aspects of the architecture that are still emerging (such as database schemas for metadata/rich data and aggregation) and all groups have committed to working on a mutually acceptable solution. | ||
Revision as of 18:15, 12 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 challlenge of being adopted by 3 related projects which have agreed to join or use ceilometer:
- Synaps
- Healthnmon
- StackTach
- 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?
Discussion with Healthnmon and sandywalsh have been deep and involved. We believe their suggestions are still obtainable with only slight modifications to Ceilometer architecture without changing the fundamentals. 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, provides a solution which:
- allows lean collection of metrics from supporting projects that send events on the Oslo bus
- permits regular fetching of data via a pull mechanism for non-notification-generating projects (i.e. Swift)
- allows more intrusive data collection for non-supported projects via an optional agent mechanism
The same measurements can then be retrieved at different intervals and republished to multiple destinations though a YAML-based configuration mechanism, thus allowing seamless integration of multiple projects around Ceilometer without forcing the use of a single database and API.
There are still some aspects of the architecture that are still emerging (such as database schemas for metadata/rich data and aggregation) and all groups have committed to working on a mutually acceptable solution.
Testimonials
- Rackspace
- Rackspace has committed considerable resources to taking the lessons learned from developing and deploying StackTach into Ceilometer (StackTach will be twilighted once comparable functionality is available). Rax has documented some of their discussion points (here: http://wiki.openstack.org/RaxCeilometerRequirements) and we will working through those in the public channels.
- Healthnmon
- Redhat
- Red Hat has committed two core developers to the project during the Grizzly release cycle, concentrating on rationalizing the nova interaction model, helping shape the v2 API, packaging for Fedora/EPEL/RHEL, and laying the groundwork for metrics & monitoring support. We expect this committment to continue into the Havana cycle.
