Difference between revisions of "Governance/Proposed/Ceilometer"

Revision as of 19:15, 5 July 2012

Ceilometer Incubator Application

Project codename: Ceilometer

Summary (one sentence abstract of the project): The project aims to deliver a unique point of contact for billing systems to aquire all meters they need to establish customer billing, across all current and future OpenStack core components.

Detailed Description:

What is the purpose of the project and vision for it?

• Provide efficient collection of metering data, in terms of CPU and network costs.
• Allow deployers to integrate with the metering system directly or by replacing components.
• Data may be collected by monitoring notifications sent from existing services or by polling the infrastructure.
• Allow deployers to configure the type of data collected to meet their operating requirements.
• The data collected by the metering system is made visible to some users through a REST API.
• The metering messages are signed and non repudiable (http://en.wikipedia.org/wiki/Non-repudiation)
• The project is for collecting resource usage data related to billing, but does not include any facility for recording customer billing details or actually charging customers or for transforming collected data into billing items.

Describe the relevance of the project to other OpenStack projects and the OpenStack mission to provide a ubiquitous cloud computing platform:

• Currently each production cloud deployed using OpenStack needs to re-implement it's own metering solution as OpenStack does not deliver a standard way to provide this to billing engines
• As each implements its own solution, there is
  • a massive amount of effort that is being duplicated
  • no standard way to collect information across OpenStack projects
  • potential patches to collect unavailable information, specific to each cloud deployment, that are hard to maintain.
• What public cloud does not need to bill for its usage?
• What private cloud does not need, at least, to be able to inform its users of their use and cost?
• Access to metering information (and standardization of it) is a common requirement of cloud end users

Basic roadmap for the project:

• v1 delivered with Folsom as an incubated project with all functions required to collect base metering info and provide standard API access
• v2 delivered with G as a core project with (subject to variation)
  • End-User API access to own metering information
  • Integration of information summary as an Horizon plugin
  • New agents for other OpenStack components (Quantum Engines? Heat? etc...)

Location of project source code:

• https://launchpad.net/ceilometer
• https://github.com/stackforge/ceilometer

Programming language, required technology dependencies:

• Python
• Depends on openstack-common
• Agents depend on respective OpenStack project they cover

Is project currently open sourced? What license?:

• Apache 2 licensed

Level of maturity of software and team:

• High

Proposed project technical lead and qualifications:

• Currently co-led by dachary and nijaba, election to be held at the end of July or beginning of August.
• Dachary is eNovance's research officer, more details can be found at http://en.wikipedia.org/wiki/Lo%C3%AFc_Dachary
• Nijaba is Canonical's Cloud Product Manager, some of his contribution can be found at https://wiki.ubuntu.com/NicolasBarcet

Other project developers and qualifications:

• dhellmann works at DreamHost, is a Member of the Python Foundation and some of his work is listed at http://www.doughellmann.com/projects/index.html
• jd worked at eNovance on OpenStack, more details can be found at http://julien.danjou.info/freelance#cv (note this excellent analysis about swift eventual consistency and bottlenecks)

Infrastructure requirements (testing, etc):

• Already integrated with gerrit and jenkins. Tests cases required for each submit.

Have all current contributors agreed to the OpenStack CLA?

• Yes

Status: To be completed by PPB