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 these summaries of the videos weekly; you can also catch them on the OpenStack Foundation YouTube channel. This round of interviews covers Neutron, Cinder and Ceilometer.


What Neutron’s goal is to implement services and associated libraries to provide on-demand, scalable, and technology-agnostic network abstraction.

Who Armando Migliaccio, PTL. Day job: software architect, HP Networking at Hewlett-Packard.

Burning issues


In general he says that more can be done and as soon as issues are on the team’s radar they try to prioritize and take care of them.

“Developing new features with an eye to the ‘bleeding edge’ are important aspects of any open source project, but I firmly believe that can only come without compromising what we’ve done so far. There’s no point in presenting shiny new features if we have more fundamental issues internally.”

What’s next


All the stakeholders — operators, end users, developers — have different needs, Migliaccio says. “Striking a good balance so that you can prioritize these needs in the span of a single release cycle — which is only six months long — is very challenging. In Mitaka, we want to make sure there’s progress with operability without compromising capabilities too much,” he adds.

What matters in Mitaka


“OpenStack Neutron has always been all about growth,’ Migliaccio says. “Right now, perhaps we’ve got to change gears and make sure there’s a better balance between enabling use cases and making sure we can embrace more features.”

Get involved!
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [neturon]
To get code, ask questions, view blueprints, etc, see: Neutron Launchpad Page
Neutron’s regular IRC meetings start one hour after the main openstack meeting, on the same #openstack-meeting channel:


What Ceilometer is part of OpenStack’s Telemetry project.


Who Gordon Chung, PTL. Day job: Huawei.

Burning issues

“In Tokyo we also worked with a bunch of other projects to help them figure out how to leverage the data we collect,” Chung says. “In the end, we’re a data crunching tool what you do with that data is up to you."

He cites the example of Horizon, OpenStack’s unified web based user interface. Based on user feedback, Chung said the team discovered it wasn’t clear what use case Horizon was targeting and it was creating a lot of confusion. So working with Horizon, the team created to simplify the interface. "Instead of presenting a bunch of graphics that might be misinterpreted, we decided to focus on core operations and simpler operations," he says.

What’s next

The team also plans to formalize performance testing in this cycle, he adds.

What matters in Mitaka


We’ve always been open to operator feedback, Chung says. The team did an operator survey before the Summit Tokyo and discovered the use case for the data was very wide — some operators use it for monitoring, billing, autoscaling — so given that wide scope the team realized it wasn’t possible to contain all of those functions in Ceilometer. The team decided to provide operators with sample configurations, to help users minimize typical snags and sticking points.

Get involved!

New contributors are always welcome, especially to Ceilometer and Gnocchi, whether it’s new features and bug fixes, Chung says. Team members also contribute to Oslo, where he notes that — the message queue is an important part of the entire OpenStack framework and also a “little bit neglected, so if people want to help out there, it’d be great.”
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [ceilometer]
The telemetry project team holds a meeting in #openstack-meeting: every week on Thursdays at 15:00 UTC.


What Cinder. The goal of the project is to implement services and libraries to provide on demand, self-service access to Block Storage resources. Provide software defined block storage via abstraction and automation on top of various traditional backend block storage devices.

Who Sean McGinnis, PTL. Day job: Senior principal software engineer at Dell.

Burning issues


There was a lot of discussion about what Cinder should actually do, he says. The main questions is whether Cinder should embrace being a commodity block storage service or whether it should take advantage of features available in the enterprise environment.

“We’re a fairly mature project now,” he says. There have been different initiatives that have come and gone, some of them were not taken as far as they might have been, such as object inheritance for drivers. So the larger question becomes how are we “meeting the needs for users without getting too caught up in the problems we’ve caused for ourselves.”

What’s next


What matters in Mitaka

In addition to the two points above, there’s a lot of discussion around high availability, and active-active deployments of the Cinder volume service, he says. “There are some ways you can get that now, but it’s not really supported in Cinder and there are few ‘gotchas.’ We want to make sure we can support Cinder in a high availability active-active environment, allow users to scale it out, and have the availability they need. So if there’s one failure in their environment, doesn’t cause end users of their cloud services to be locked out from provisioning,” he says.

Get involved!
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [cinder]
Participate in the weekly meetings: held in #openstack-meeting, on Wednesdays at 16:00 UTC.

Cover PhotoCC/NC