The OpenStack Blog

Category: Governance

OpenStack Technical Committee Update (July 1)

The last TC update discussed the DefCore effort being led by the OpenStack Foundation Board. The DefCore subcommittee had made some requests for input from the TC. This week we held a special meeting entirely focused on clarifying some points around DefCore and providing some responses to the questions given to us.

It’s also worth noting that prior to the meeting, Jonathan Bryce posted a very comprehensive review of the existing framework that governs OpenStack trademark usage. This thread is absolutely worth reading for a good understanding of this topic.

Scope of DefCore

The first point on the agenda was to clarify the scope of DefCore. Specifically, we wanted to clarify which uses of the trademark this effort was applicable to. There were some important points of clarification reached during the meeting on this topic. DefCore is only about the commercial uses of the trademark. Currently, this only includes the “Powered by OpenStack” trademark license program. We also understand that the board has left open the option of an “OpenStack Compatible” trademark program in the future that may have a different set of requirements than what we are discussing right now.

Jonathan clarified this very well during the meeting (at 20:25:56):

The license agreement in question is called OpenStack Powered and is intended for use with products and services that are built using OpenStack software. for instance a public cloud “FooTron Compute Powered By OpenStack”, an appliance “FooTron Appliance Powered by OpenStack”, a distribution “FooTron OpenStack”. All of those different products would be held to the same standard. in other words, they would all be required to expose the same capabilities (testable over the APIs) and include the same actual community-developed software bits (designated sections).

DefCore Capabilities

The DefCore subcommittee has been working to define a set of capabilities with associated tests that would be used as a part of the process to determine if a given OpenStack product or service was allowed to use the OpenStack mark under the “Powered by OpenStack” trademark program. They have been using a scoring system to determine which capabilities should be required. Part of the input into this scoring is “technical direction”. They do not want to include a required capability that the technical community does not view as something we want to keep around long term. The TC was asked to provide input on some capabilities where the future was unclear. We have been working on clarifying all of these points in two reviews to the OpenStack technical governance repository. We are close to reaching a final conclusion on these points.

DefCore capabilities are currently defined in a JSON file as a mapping to a set of tests. One recommendation that the TC provided was that a 1 or 2 sentence description for each capability would help provide easier understanding of the intended coverage of a capability. Otherwise, interested parties must go read each test to understand exactly what it’s attempting to verify. While this would be helpful, we all agreed that this does not actually block progress. It would just make things easier.

The final point discussed in this section of the meeting was the intersection of capabilities and designated sections of code. Generally you have to implement designated section code and deliver core capabilities, but it was clarified that designated sections of code would only be required if there is a corresponding capability that is deemed required. If a project has no required capabilities, then the use or distribution of that project is not required.

Designated Sections

This was the most controversial part of the meeting. The DefCore committee had requested that the TC provide a proposed set of designated sections of code. This input would then be used as the basis for what code is required under the “Powered by OpenStack” trademark license program. After much discussion, the TC was able to reach consensus on this topic and a response was provided in this meeting.

One of the primary responsibilities of the TC is to define the OpenStack integrated release which is released every 6 months. This is the set of things that we vouch for. We have a defined process with a set of requirements projects must satisfy to apply for incubation and potentially eventually graduate to be a part of this integrated release. Defining a subset of the integrated release would make the TC appear to endorse or encourage replacing part of their work with proprietary alternatives. The TC is an elected representation of the contributors to the project and as such it does not feel it should declare a subset of the integrated release less important than the rest.

We do value that the Apache license provides the option of replacing part of the code with alternative solutions, and we respect that it’s the board prerogatives to determine trademark use policy. So we would like to clearly recognize that it’s the board’s right to define the subset of the integrated release required by commercial trademark license agreements (such as the “OpenStack Powered” trademark program), and therefore they should have final say on “designated sections”. A process to achieve that was suggested by Mark McLoughlin on the Defcore list, where the Board would propose designated sections and ask the wider community for comments on it, then make the final calls based on that feedback.

OpenStack Technical Committee Update (June 25)

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.

OpenStack Technical Committee Update

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.

Openness

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.

Glance

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.

Designate

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!

Election Results for Individual and Gold Directors

Each January two of the Foundation member classes hold elections to determine their Board representatives for 2014. The Gold Members held their election on January 6th-7th while Individual Members elected their Directors between Jan 12th-17th.

Today the 2014 election of Individual Directors has closed and the official results are in. The elected and appointed directors will be seated at the next board meeting, at 12:00pm PST on January 30th. Thank you to everyone who participated in this year’s Individual Director election and congratulations to our new and returning directors. The composition of the board will be as follows:

Individual Directors

  • Tim Bell
  • Yujie Du
  • Alex Freedland
  • Rob Hirschfeld
  • Vishvananda Ishaya
  • Mark McLoughlin
  • Monty Taylor
  • Troy Toman

Gold Directors

  • Simon Anderson
  • Randy Bias
  • Tristan Goode
  • Joshua McKenty
  • Boris Renski
  • Sean Roberts
  • Imad Sousou
  • Lew Tucker

Platinum Directors

  • Alan Clark
  • Eileen Evans
  • Toby Ford
  • Chris Kemp
  • Van Lindberg
  • Todd Moore
  • Brian Stevens
  • John Zannos

Women of OpenStack, Why?

Why do we get together in person each Summit? Let me tell you. A picture is worth a thousand words, so here are some pics from our Women of OpenStack boat outing Monday night on the harbor. The grey fog was everywhere and we couldn’t go on deck because it was just too wet. The buildings lighting up are an amazing sight, you can hardly capture the lights in photos. And I can hardly capture the value of getting together with other women in OpenStack at the Summit, but here goes.

Untitled

We had a great time on the boat, and at happy hour afterwards I had an awesome chat with a woman from IBM who is pretty much my neighbor! It’s a small world with tight connections in Austin for high-tech women. It seems impossible with the numbers game we’d know each other’s schools, streets, neighborhoods, and so on, but in reality we’re rare enough birds of a feather that it is natural for us to get together and know each other well.

Why do we get together apart from the rest of the conference? We have a couple of themes for our meetups, we talk about outreach to more women, especially in education as early as elementary school and definitely through college. Also, I got to meet our GNOME Outreach Program for Women intern, Terri Yu, in person! That’s a huge part of these in-person gatherings, getting to know each other personally. But we also want to find concrete ways to make our meetings meaningful. We talk about a few tracks for our goals – outreach, education, career planning and mentoring. We came up with some ideas for our goals, and we keep discussing each Summit. It’s like a design summit session for women of OpenStack. In between Summits we stay in touch on LinkedIn though I also serve as an API, ha ha.

We look for speaking opportunities for women in the cloud. We have held workshops geared towards outreach to women, introducing lots of technical women to OpenStack. For example, this past year Iccha Sethi, Jessica Lucci and I ran a workshop at the Grace Hopper Open Source Day, and Anita Kuno, Lyz Krumbach Joseph and Ryan Lane ran a CodeChix workshop. We generally forge the bonds that hold together a common minority by talking about schools, parenting, gin as a vegetable, shoes, traveling, and how does this OpenStack Neutron plug-in work, anyway?

There are so few of us that we need to be diligent about our outreach and staying connected. I blogged about a question related to under representation of minorities in the Technical Committee on my Reflecting on the OpenStack Summit in Hong Kong. We need to be hyper-vigilant about imposter syndrome, uncovered by researchers who found that many high-achieving females tended to believe they were not intelligent, and that they were over-evaluated by others. Believe me, I have to fake it to make it daily.

Our culture as a community may reward the most confidence, but in reality as we grow as a community it’s important to understand that some cultures don’t view confidence in the same way, and some people will not naturally exude confidence. We’re also looking at English-as-a-second-language increasing in prevalence in our community, and a former OPW (Outreach Program for Women) intern Anita Kuno recently edited our Technical Committee charter to be gender-neutral. All of this matters, all of these actions answer the valid question, “Why?” I hope you’ll join us in outreach efforts, together we make OpenStack better for all contributors.

Reviewing how Blueprints are handled

OpenStack Compute Tech Lead Russell Bryant has triggered an important discussion on the OpenStack Development mailing list about the process to review blueprints. The Blueprints wiki page currently assigns to Project Tech Leads the task of assigning priority to the blueprints and Russell is suggesting that a wider group of people in the community shares such responsibility..

Blueprints are used by project leaders to track development of significant features in all OpenStack programs: a blueprint is made of a title and a brief description, plus a URL to a wider description of architecture and specifications (usually a wiki or etherpad page).  Given the growing size of OpenStack code base, scaling development operations is increasingly hard and one person cannot handle reviewing all the proposed blueprints and set priorities in a way that guarantees finalization.

This brings us to the second issue that needs to be addressed: managing expectations of new contributors. With so many blueprints being proposed it’s hard for a PTL to be accountable for developers to deliver the code based on blueprint’s priorities. Since the PTL used to set the priority for the blueprint, it is hard to held him/her accountable when the code is not delivered accordingly. There is clearly a separation of powers between the person evaluating the blueprints, the developers that will implement them and the reviewers that will review the code submitted.

Russell’s proposal is to assign the responsibility to review the blueprints to the same team of people that will be responsible for reviewing and approving the code during the implementation phase, the core reviewers. The role of the PTL will still be to set the deadlines for the blueprints and to make sure that the roadmap for the program is sound. The core reviewers will then be sharing with the PTL the responsibility and accountability for the deliverables at each release milestone

In the discussion that’s following on the mailing list there are also proposals to include user input while setting the priorities for blueprints. There are risks also associated with this setup. So far, the process has been discussed only taking into account the needs of OpenStack Compute. The project is the largest OpenStack project by number of blueprints, making it the first to need reviewing the existing process. However, the expectation is that several other OpenStack projects may evolve to this point in the future and this is an important test for that time. As such, we welcome holistic feedback: join the discussion on the development mailing list and in Hong Kong.

OpenStack Governance: Electing Technical Leaders For Next Development Cycle

An important part of OpenStack’s culture is to elect its tech leaders every six months: we’re in the process of electing the Project Tech Leads for the next 6 months release cycle. Our governance model based on merit is one of the strong points of our community. Except otherwise-noted in the program description, the electorate for a given program PTL election are the Foundation individual members that are also committers for one of the program projects over the Grizzly-Havana timeframe (from 2012-09-27 to 2013-09-26, 23:59 PST).

This week from Sep 20 to Sep 26 the candidates to PTL positions can offer themselves. The e-voting booths will be open from Sep 27 to Oct 3. Elections will be held using CIVS and a Condorcet algorithm (Schulze/Beatpath/CSSD variant). Any tie will be broken using TieBreaking rules.

After the PTLs are elected we will also elect the members of the Technical Committee. This is the first election with the new TC charter: we renew 11 TC seats for this election. Candidates ranking 1st to 6th will get one-year seats, and candidates ranking 7th to 11th will get 6-month seats.  The electorate for TC election are the Foundation individual members that are also committers for one of the official programs projects over the Grizzly-Havana timeframe (from 2012-09-27 to 2013-09-26, 23:59 PST).

Any member of an election electorate can propose his/her candidacy for the same election (except the two TC members who were elected for a one-year seat last Spring, Vishvananda Ishaya and Thierry Carrez). No nomination is required.  More details on the dedicated wiki page.

Addressing the topic of ‘Core’ through Spider

The word “core” carries with it a wide range of meaning and implication for those involved within the OpenStack community. What we’ve discovered through ongoing discussions is that the goals of one audience simply aren’t necessarily the goals of the other audiences – in fact, in some cases, they’re opposed!

We first began the journey to refine the definition of core through a work effort called IncUp.  IncUp was a combined effort of TC and board members that resulted with improvements to the Incubation process. That effort also helped draw out the complex nature of defining core.  The complexity is due to the varied impact core has upon OpenStack users and contributors, as well as the ecosystem as a whole.

Addressing The Problem
On assignment from the Board, Rob Hirschfeld and I began meeting to further the progress of defining core. The first step in this process was to examine and define the goals of each audience, which Rob detailed in a series of blogs[1] outlining the thought processes we went through.

Shortly after we began this process, we quickly realized that the goals amongst these various audiences would either be aligned or in tension. Using different colors to map the goals and tensions on a whiteboard, we created a massive multi-colored “spider” graph, which became more of a mind map. Thus, we refer to the current effort as the “spider discussions” or simply spider.

Problem Statement/Goal
At the highest level, this spider effort is about advancing the OpenStack mission of producing the ubiquitous Open Source cloud computing platform. The key efforts within this process include defining the set of components, processes and criteria needed to protect the brand, provide users a good experience, and reinforce a collaborative community.OpenStack marks are the tools that the Foundation has to define and defend those keys.
In order for OpenStack implementers to use the OpenStack mark, the Board was chartered to provide specific and verifiable criteria. However, these do not currently exist in a usable form.  Thus, our “what is core” discussions and efforts seek to determine those criteria.
Statements of Position
Spider focuses on breaking down those criteria of core into referenceable position statements.  Those statements will form a basis to draw upon so that we may keep the decision making – and eventual implementation – on a progressive track.There are currently 10 evolving position statements:1.     Implementations that are core can utilize the OpenStack trademark (OpenStack™)
1.     This is the legal definition of core, as well as why it matters to  the community.

  1.  We want to make sure that the OpenStack™ mark means something.
  2. The OpenStack™ mark is not the same as the OpenStack brand; rather, the Board uses its control of the mark as a proxy to help manage the brand.

2.     Core is a subset of the whole project

  1. The OpenStack project is intended to be a broad and diverse community with new projects entering incubation, with new implementations frequently added. This innovation is vital to OpenStack but separate from the definition of core.
  2. There may be other marks that are managed separately by the foundation and available for the platform ecosystem at the Board’s discretion.
  3. The “OpenStack API Compatible” mark is not part of this discussion and should be not be assumed.
3.     Core definition can be applied equally to all usage models

  1.  There should not be multiple definitions of OpenStack, regardless of the operator (public, private, community, etc.).
  2. While expected that each deployment is identical, the differences must be quantifiable.

4.     Claiming OpenStack requires use of designated code frameworks

  1. Implementations claiming the OpenStack™ mark must use the approved API framework code.\
  2. Entities which only pass all the tests but do not use the API framework will not be considered or be approved as part of OpenStack.This prevents entities from using the API without joining the community, as well as surfaces bit-rot in alternate implementations to the larger community.
  3. By implementing this requirement,  interoperability is greatly improved, as there is more shared code between implementation

5.     Projects must have an open reference implementation

  1. OpenStack will require an open source reference base plug-in implementation for all projects (if not part of OpenStack, license model for reference plug-in must be compatible).
  2. We define a plug-in as alternate backend implementations with a common API framework that use common _code_ to implement the API.
  3. This establishes the expectation that projects (where technically feasible) will implement plug-in or extension architecture.
  4. This is already in place for several projects and addresses ecosystem support, further enabling innovation.
  5. Reference plug-ins are, by definition, the complete capability set. It is not acceptable to have core features that are not functional in the reference plug-in.
  6. This will enable alternate implementations to offer innovative or differentiated features without forcing changes to the reference plug-in implementation.
  7. This will also enable the reference to expand without forcing other alternate implementations to match all features and recertify.

6.     Vendors may substitute alternate implementations

  1. If a vendor plug-in passes all relevant tests then it can be considered a full substitute for the reference plug-in.
  2. If a vendor plug-in does not pass all relevant tests then the vendor is required to include the open source reference in the implementation.
  3. Alternate implementations may pass any tests that make sense and should add tests to validate new functionality.
  4. They are also required to have all the must-pass tests (see #10) to claim the OpenStack mark.

7.     OpenStack implementations are verified by open community tests

  1. OpenStack implementations by vendors must achieve 100% of must-have coverage.
  2. Implemented tests can be flagged as must-have required list.
  3. Certifiers will be required to disclose their testing gaps.
  4. This will put a lot of pressure on the Tempest project.
  5. Maintenance of the testing suite will become a core Foundation responsibility, which may require additional resources.
  6. Implementations and products are allowed to have variation based on publication of compatibility.
  7. Consumers must have a way to determine how the system is different from reference (posted, discovered, etc.).
  8. Testing must respond in an appropriate way in BOTH pass and fail (the wrong return rejects the entire suite).

8.     Tests can be remotely or self-administered

  1. Plug-in certification is driven by Tempest self-certification model.
  2. Self-certifiers are required to publish their results.
  3. Self-certifier are also required to publish enough information that a third party could build the reference implementation to pass the tests.
  4. Self-certifiers must include the operating systems that have been certified.
  5. It is preferred for self-certified implementations to refer back to an OpenStack reference architecture “flavor” instead of defining their own reference (a way to publish and agree on flavors is needed).
  6. The Foundation needs to define a mechanism of dispute resolution (i.e. a trust but verify model).
  7. All ecosystem partners need to make a “works against OpenStack” statement that is supportable.
  8. An API consumer can claim working against the OpenStack API if it works against any implementation passing all the “must have” tests.
  9. API consumers can state they are working against the OpenStack API with some “may have” items as requirements.
  10. API consumers are expected to write tests that validate their required behaviors (submitted as “may have” tests)

9.     A subset of tests are chosen by the Foundation as “must-pass”

  1. An OpenStack body will recommend which tests are elevated from “may-have” to “must-have.”
  2. The selection of “must-pass” tests should be based on quantifiable information when possible.
  3. Must-pass tests should be selected from the existing body of may-pass tests.  This encourages people to write tests for cases they want supported.
  4. We will have a process by which tests are elevated from “may” to “must” lists.
  5. Essentially, the hope is that the User Committee will nominate tests that elevate to the Board.

10.  OpenStack core means passing all “must-pass” tests

  1. The OpenStack Board owns the responsibility to define core (to approve ‘musts’).
  2. We are NOT defining which items are on the list in the Spider effort; rather, just making the position that this is how we will define core.
  3. May-have tests include items in the integrated release, but which are not core.
  4. Must-haves must comply with the core criteria defined from the IncUp committee results.
  5. Projects in Incubation or pre-Incubation are not to be included in the “may” list.

For a quick visual way to understand how these position statements interconnect Rob posted, in his blog series, an ‘OpenStack Core flowchart’. [2]

Help Us Finalize the 10

These position statements are an ongoing work in process. It is our goal to finalize them for the November Board meeting and Hong Kong Summit. Yet in order to meet that goal, we want your help and, as such, would love to hear from you. I encourage you all to strike up a conversation on IRC with Rob, myself or any board member, or simply post your feedback to the Foundation mailing list. We’re looking to you to help us reach the goal of the Foundation’s mission!

Alan Clark
OpenStack Board Chair

[1] http://robhirschfeld.com/2013/07/23/introducing-the-openstack-spider-graph-untangling-our-web-of-interdependencies/
[2] http://robhirschfeld.com/2013/08/07/visualizing-the-openstack-core/

The All New OpenStack Travel Support Program

The OpenStack Foundation announces the availability of travel grants under the OpenStack Travel Support Program. The program’s aim is to facilitate participation of key contributors to the OpenStack Design Summit covering costs for travel and accommodation. The Travel Support Program is based on the promise of Open Design, one of the founding principles upon which the OpenStack project is built.

Key contributors are contributors whose presence is specifically relevant for the topics to be discussed at the Summit they’re applying to. Relevance of somebody’s presence is never evaluated in general ways: it’s always relative to the content being discussed at the specific Summit. The OpenStack Foundation will set aside a fund to support this program. The total amount of the fund is to be divided among the key contributors.

How to apply

All contributors to OpenStack (developers, documentation writers, organisers of user groups around the world, Ask moderators, translators, etc) are invited to submit a request. PTLs and code reviewers also are requested to propose candidates.

  • Candidates apply on the online form starting today with the deadline of July 31
  • Travel Selection Committee evaluates entries based on criterias stated on the wiki page Travel Support Program
  • Travel Agent coordinates with key contributors.

The OpenStack Foundation will coordinate directly with the approved key contributors to arrange for their travel, according to the level of funds granted. More details on the wiki page Travel Support Program.

Who’s growing the OpenStack Pie?

Stackalytics OpenStack Contributions. Presented by Mirantis

The OpenStack community is nearing 10,000 members in nearly 100 countries, with foundation support by more than 200 companies. Wondering who all those people are and what they’re doing? We did too. That’s why today we are announcing the release of our latest open source tool, Stackalytics.com.

Statistics are critical to turning data into information, and everyone needs detailed information in order to make decisions, especially in fast moving cloud technology. Since here we practically wallow in code day in and day out we find it useful to know what’s really going on with our development, and how our fellow contributors are participating in the community.

OpenStack Analytics: Stackalytics

Pie Chart of OpenStack contributions dataStackalytics is a data visualization tool that collects data from GitHub and presents it in an array of useful forms. Not only can Stackalytics break down the data into companies, projects, and contributors, but it also lets you track commits and overall lines of code.

All of the collected data is collated and linked so you can drill down into different projects, contributing companies, and even individual contributors for a more detailed view. Want to know how much attention the Cinder project is getting for the upcoming Havana release? Just choose Havana in the pulldown at the top, then click on the project name. Do you want to see what work has made Mirantis the #4 code contributor to OpenStack? Just click the company name.

Lines and Commits

One of the more important metrics that illustrates work hours and productivity is the number of commits made against the lines of code produced by developers. A commit is a unit of work that is performed by a developer when they create, fix, or delete some code in a particular module. This code is then processed by Gerrit, Jenkins, and/or SmokeStack, reviewed by at least two core developers, and is finally merged into the Master Branch. Lines of Code (or LoC) is the number of actual lines of code that are created, fixed, or deleted.

Sample OpenStack contribution data by project

The difference between these two is critical because the values can show project managers where the team’s productivity is yielding results. Consider a developer who produces 5,000 lines of code and yet only has a handful of small commits. Alternately, a developer who produces 400 lines of code might have dozens of commits. This kind of information can help project managers better guide their projects and developers. Additionally, you can compare one company’s progress with your own or others. For greater detail into the development tracks being taken on various projects, you can also examine the project blueprints used by the developers to manage the planned changes and improvements.

Of course, that information won’t mean as much if you can’t effectively navigate the collected data. We’ve set up the data view to be configured to show what you are looking for. You can pick individual releases and see lines of code or just commits. You can choose to look at the project view, giving you a 10,000 ft. view, or drill deep into module details to see exactly which commitments have been made by which developers.

Search and Drilldown

In addition to the view selectors, you can also dynamically search for information. Each column of data has a search field at the top. Enter search terms and watch as the results change, which helps you find what you’re looking for. Every list has a search field, making it faster and easier to find something specific. Finally, if the default of 25 results isn’t enough, you can use the selector to change how many items are displayed.

Now that you’ve seen the picture of top-down results of OpenStack community work, you might be interested in bottom up. First, if you’re trying to see how quickly changes are getting into OpenStack, check out the Zuul project page. Unlike its predecessor projects such as you might find at The Apache Software Foundation, OpenStack is continuously integrated as code is committed and validated; Zuul provides pipeline oriented project gating and automation system that produces a continuously integrated updated code base. The rate of change is graphed at the bottom. Second, if you’re interested in examining the pulse of specific changes to specific projects day-to-day, take a look at the OpenStack Foundation’s activity trackers. The browser gives a day-to-day pulse of activities at the micro-level. You can also search the individual changes based on who made them at the company and individual level using the OpenStack Community Insights browser.

Stackalytics Project Roadmap

As you come back up out of the depths of day-to-day activity, you can get a sense of how much developer work OpenStack and its associated projects represent. Helping visualize the collective results, on a scale of releases you might choose to adopt — that’s what we set out to do with Stackalytics. There are other projects and other ways to slice the data, and we’re only just getting started.

A few future improvements you can look forward to include that addition of review statistics to lines of code and commits, a well-documented API that will enable developers to leverage Stackalytics data, and Stackalytics widgets you can add to your website by copying and pasting a few lines of code. We’re also working on an interface and workflow for peer driven corrections and updates to committer attributions. (In other words, if you leave one company and go to another, you can provide this data yourself so your work is attributed correctly.)

Want to see something else? We’ll have the project posted on stackforge soon so you can hack at the code yourself.

David M. Fishman is VP of Marketing at Mirantis.

Back to top