Tag: technical committee

OpenStack Technical Committee Update (June 25)

June 25th, 2014 — 11:23am

Two weeks ago, Russell Bryant inaugurated a series of blogposts about what the Technical Committee (“TC”) is working on. We will regularly post about the outcomes of the TC meetings, and rotate writers to give all TC members a chance to participate and describe what happens in their own words. This post will focus on what happened during the last two meetings.

The TC has several missions, and the topics we cover in TC meetings generally fall into one of them.

Mission #1: Integrated release contents

One of the missions of the TC is to determine what is part of the OpenStack “integrated release” that we collectively produce every 6 months. We manage the “incubation” process, through which selected projects can become part of the integrated release. We also keep an eye on already-integrated projects in case their scope evolves.

That’s the case currently for Glance, whose mission is evolving from cataloging and serving Nova disk images to cataloging and serving other artifacts consumed by other OpenStack services, like for example Heat templates. This scope evolution has been under discussion at the last two meetings. The principle of expanding Glance’s scope is pretty much accepted at this point, but the precise words to describe the new scope are still under discussion.

In order to set clear base expectations for projects in the incubation/integration process track, last cycle the TC came up with a reference document listing all the requirements for incubation, integration and the first integrated cycle that are consensual across TC members. This document is constantly revisited as we continue to raise the quality and convergence bar between integrated projects.

Last two meetings we have been discussing adding a translation support requirement for projects wishing to graduate from incubation. The main objection to it at this point is the lack of automated testing of the translated strings (which resulted in undetected I18N problems in the past). It looks like when this is addressed, this requirement will probably make it to the reference document.

Raising requirements for new entrants is one thing, but sometimes existing integrated projects do not fill those new requirements. This creates a gap that we need to address. During this cycle we reviewed most existing integrated projects (Heat and Swift are still pending). When a gap was raised, PTLs responded with a proposed “gap coverage plan” to address it.

The last project to go through that exercise was Glance, where a single gap around testing coverage was raised. Mark Washenberger (Glance PTL) created a gap coverage plan to address it and that plan was blessed by the TC at the last meeting.

Having plans is a good thing, but we also need to check that projects meet the deadlines that they set in such plans. Last week, after the juno-1 development milestone, we reviewed the progress on gap coverage plans. Ceilometer plan is on track, still targeting the juno-2 milestone for fully covering the gap. Horizon plan is mostly on track. Neutron has an ambitious gap coverage plan, and work on all gaps has started; gap 4 is a bit late (was planned to be completed by juno-1), but it’s also been determined to just be one API call. Trove plan is on track, and work started on all items.

Finally, having responsibility over the integrated release also means making sure we use terminology across integrated projects consistently. An issue was raised about the use of “certified” terminology to qualify CI testing on some projects. After open discussion on the -dev mailing-list and at the TC meeting, there was agreement that “certified” terminology was too loaded and should be phased out in favor of some variation around “tested”.

Mission #2: Representation of technical contributors

The TC is a directly-elected body representing all the technical contributors to the project. It is the final decision-making entity over technical matters in OpenStack as a whole. Some issues that can’t be solved at a lower level are sometimes escalated to the TC for final resolution, and the TC is also a convenient conduit for other OpenStack governance bodies to ask for general technical input.

Two issues were brought to the TC recently. The first one is about expected election behavior for our technical elections (PTLs and TC members). Our current election procedure doesn’t clearly describe expected behavior, and a proposal was raised to cover that. While everyone agrees on what is acceptable behavior and what is not, there are two ways of addressing issues if they arise. One is to piggy-back on the Community Code of Conduct, which clearly states that you should respect the election process. The other is to call out out-of-line behavior and trust the voters to make their own judgment about it. Both options are and will stay available, but we are still discussing which of those options (if any) we should encourage by making it part of the TC resolution. This discussion is on-going and will continue in a future meeting.

The other issue being brought to the TC were requests from the Foundation Board of Directors “Defcore” subcommittee for technical input to use as part of their work on trademark rules. There are two types of requested inputs. One is to provide for each project “designated sections” of code that you need to run in order to use the “OpenStack” trademark. The other is to give precise scoring for “core capabilities”: for each capability, indicate whether it’s part of the TC future direction or if it’s on its way to be deprecated.

While those inputs are technical (and we even voted on guidelines to help coming up with answers), some TC members expressed clearly their discomfort. Asking the representation of OpenStack contributors to designate parts of OpenStack that may just be replaced by proprietary alternatives (while still being called “OpenStack”) just crosses the line as to what they consider acceptable. Our “technical” answer might be read as an endorsement, or collaboration toward a behavior we don’t really want to encourage.

This tension has been surfacing every time Defcore was discussed at the TC meeting, and it’s difficult to address it between two topics in a one-hour online meeting. We have therefore scheduled a Defcore-specific TC meeting for July 1st (20:00 UTC in #openstack-meeting on Freenode IRC), and will try to clearly list concerns beforehand to ensure meeting clarity.

Comment » | Communication, community, Governance

OpenStack Technical Committee Update

June 11th, 2014 — 4:29pm

The OpenStack Technical Committee (TC) meets weekly. During the meeting on 2014-06-03, one of the topics we discussed was the relatively low turnout for the TC election as compared to the PTL elections. The most productive thing to come out of that discussion was that we needed to do a better job of communicating what the TC is working on and why it is important. As a result, we will be posting regular updates about the TC to the OpenStack blog. This first post will likely be a bit longer as it’s important to set up some of the context for the things we are currently discussing.

How the TC was formed is described in the history of OpenStack open source project governance  by the current chair of the TC, Thierry Carrez.


Open governance is an important value held by OpenStack and the TC wants to be as open as possible. In addition to these regular updates, you can find the details of everything we do in a few other places. The archives of the openstack-tc mailing list are open. Our weekly IRC meetings are public and logged.

All project governance work is managed in a git repository and changes are reviewed in gerrit in the same way that we review code. Everyone that is interested is invited to comment on proposed governance changes. You can find a list of changes under review here. You can find a list of previously approved changes and the discussions that happened on their reviews here.

Project Incubation and Graduation Requirements

One of the responsibilities of the TC is to manage the set of projects that are included in the OpenStack integrated release. New projects may apply to be incubated. Incubated projects will later be reviewed for graduation from incubation. A graduated project is a part of the integrated release.

As OpenStack has grown, it became clear that we needed to be much more clear around our expectations of projects for incubation and graduation. Over the last year we worked to formalize these expectations in a document in the governance repository. We approved the first version of this document on December 2, 2013. We have been updating it ever since as more issues need to be clarified. You can find the latest version of that document in the Governance git repository.

Toward the end of the Icehouse development cycle, we started a process of going through all projects already in the integrated release and evaluating them against this criteria. For any project that has gaps against these expectations, we require that the PTL present a plan for addressing these gaps during the Juno cycle.


The latest project review was for Glance, during the TC meeting on 2014-06-10. The only gap found for Glance was around tempest test coverage. Specifically, Tempest does not cover uploading a real binary image to Glance. The Glance PTL will now come up with a plan to address this gap and the TC will review progress against this plan throughout the Juno cycle.

We actually spent quite a bit of this meeting talking about Glance. The most controversial topic is around the proposal to increase its scope. Glance is currently focused on disk images. There is a proposal against the governance repository to expand its scope to cover a more general definition of artifacts. The particular use cases that inspired this direction for Glance is the desire to store things like Heat or Murano templates. In the end, there seems to be broad support for the general direction proposed. We still have some work to do to get the wording of the mission statement in a form that everyone is comfortable with.

Finally, the Glance project brought an important cross-project API consistency question to the TC. Specifically, they have an alternative method for how they would like to expose actions through their API which is different from how Nova does it currently, for example. There was support for the specific proposal. However, it raises the larger question about how we go about best working toward cross project API consistency. We would love to have someone lead an effort to create a cross-project API style guide for OpenStack, but it’s unclear who will do it and exactly who would review and approve the content. I expect this to be an ongoing discussion.

You can find the full mailing list thread that spawned this API discussion in the archives starting in May and continuing in June.


Another project that has received a lot of attention recently is Designate, which provides DNS as a Service for OpenStack. This is a sorely needed feature for OpenStack deployments so I’m very happy to see the progress made in this area.

The project recently applied for incubation. This is actually the second time that Designate has applied for incubation. The first time was one year ago, in June of 2013. After the first application, the TC concluded that it was a bit too early to incubate the project. There were various concerns, but the primary one was the level of involvement in the project, in terms of individuals and separate companies.

Designate has matured a good bit over the last year and I’m proud to announce that the application has been approved. Designate is now an incubated project!

The earliest Designate will be included in the integrated release would be the K release. Given that we’re already well into the Juno cycle, the L release seems more realistic. This is a topic that the TC would revisit at the end of the Juno development cycle.

Future Updates

We want to make these updates from the TC as useful as possible. If you have any comments or suggestions, please let us know!

Comment » | Communication, community, Governance

OpenStack Governance Elections: Technical Committee

September 14th, 2012 — 2:15pm

Now that we have elected the Project Technical Leads for the next release, the OpenStack community is called to elect the last 3 members of the OpenStack Technical Committee. Per section 4.1(b) of the OpenStack Foundation bylaws, the Technical Committee (“TC”) is a technical meritocracy managing all the technical matters relating to OpenStack. It replaces the “Project Policy Board” from the old governance.

Anyone who would like to be a candidate for this election may now submit their names!

Valid candidates, like voters, must be an Active Technical Contributor, which means:

  1. they have contributed at least one change to one of the official OpenStack projects[3] (over which the TC has final authority) in the year preceding 23:59 PST, August 29, 2012; and
  2. they are an individual member of the Foundation by 23:59 PST, September 13, 2012.

The 10 already-elected members (recently-elected PTLs and PPB members that were elected to a one-year seat last Spring) cannot run.

To submit your name for the ballot, please send an email to the [email protected] mailing list with the following information included:

Subject: TC candidacy
Body: Ideally, a description of your platform, your technical/leadership credentials, experience, etc. — in short, anything that will be useful
for voters to assess your qualifications as a member of the OpenStack Technical Committee.

Your candidacy will then be validated, on the same thread, by one of the election officials (Stefano Maffulli, Duncan McGreggor, Thierry Carrez).

The deadline to submit your candidacy is 23:59 PDT, September 19. The election will then run from September 21 to September 27.

There is more information on the election process, including how we’ll break any tie on the wiki. Let us know if there’s anything more we can do to make this process as transparent as possible!

Comment » | Communication, community

Back to top