Meet the project team leads (PTLs) and find out how to get involved.


Each release cycle, OpenStack project team leads (PTLs) introduce themselves, talk about upcoming features for the OpenStack projects they manage, plus how you can get involved and influence the roadmap.

Superuser will feature weekly summaries of the videos; you can also catch them on the OpenStack Foundation YouTube channel. This post covers Sahara and Telemetry.


What Sahara
The project provides a simple means to provision a data-intensive application cluster (Hadoop or Spark) on top of OpenStack.

Who Vitaly Gridnev, PTL. Day job: Software engineer at Mirantis.

Burning issues


Sometimes it’s hard for users to understand what’s happening with Sahara, Gridnev says, so troubleshooting and monitoring are key. Some also have a hard time managing and preparing Hadoop clusters so those are key areas for improvement.

What’s next


What matters in Newton



Looking ahead to Ocata, he says that some changes are afoot. If Sahara dies when the cluster is being provisioned, there’s currently no way to restore it, “we’re going to improve that,” he added.

Get involved!

Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [sahara]
The project holds weekly team meetings: that alternates times and locations.The meetings are held on Thursdays at the following times/places:

  • 18:00 UTC in #openstack-meeting-alt
  • 14:00 UTC in #openstack-meeting-3


What Telemetry
The telemetry requirements of an OpenStack environment are vast and varied, they include use cases such as metering, monitoring, and alarming to name a few. The scope of these uses cases are diverse and beyond the scope of a single project and team. Currently, the telemetry project provides a set of functionality split across multiple projects; each project designed to provide a discrete service in the telemetry space.

The current set of projects are managed by the telemetry team are:

  • Aodh – an alarm service
  • Ceilometer – a data collection service
  • Gnocchi – a time-series database and resource indexing service

Who Julien Danjou, PTL. Day job:, principle software engineer at Red Hat.

Burning issues


About the documentation, Danjou says “we’re not the worst project in OpenStack for it, but we know that people struggle with it for a lot of things in Ceilometer and Aodh,” he says. “We have terrific documentation for Gnocchi, [where] the policy is ‘no documentation, no patch merged’…We are trying to do that for the other projects, too.”

What’s next


“There’s nothing to configure with Gnocchi, it just works. We’re trying to do that with Ceilometer. You can configure it to meet your needs, but you don’t have to read the whole documentation to use it,” he added.

What matters in Newton


This cycle the team is starting a new project, Panko, an event storage and REST API for Ceilometer.

Danjou says it’s the same tests, same documentation and “we’re not going to change anything, we’re just moving the code into a new repository. There are a lot of people using Ceilometer but not using the events part because it started a couple of years ago and it’s not really finished. It’s usable but the API is quite simple, and there’s no need to deploy it every time you deploy Ceilometer. ”

Get involved!
“We’re a very small team so if you’re interested in helping us, Telemetry would be very happy to have you,” Danjou says, adding that the best way to get started is on the #openstack-telemetry IRC channel. “It’s an interesting and growth topic so feel free to join us.”

Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [telemetry]
Check the Telemetry page for meeting times for each project.

Cover Photo // CC BY NC