The OpenStack Blog

Category: Governance

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.

Discussions at Breakfast with the Board – OpenStack April 2013 Summit

It is an exciting time to be part of the OpenStack community.  It was a great conference with lots of momentum around OpenStack.  The speed and growth of the community is amazing.

Tuesday morning during the Summit, we continued the tradition of Breakfast With The Board (BwtB).  We wish to thank all who participated.  As board members we very much appreciated your comments of support, feedback and ideas.  We heard many positive and encouraging comments  and participated in many lively discussions.

Through this writeup we would like to share what we heard.   There was a wide variety of topics discussed, including:

Summit Design Session Growing Pains
Despite a variety of changes tested and introduced over the past Summits, accommodating all who wish to participate in the Summit design sessions continue to exhibit growing pains.  The design sessions are “intended to be small, focused developer working sessions where the roadmap is set by active contributors on the project.”  With such a description it is easy to see why so many business persons, users, and developers want to participate or listen in. Yet the fear is that a varied large audience will decrease session output.

Many ideas were voiced at the BwtB as to how to address the issue, including room moderators, attendee prioritization, seating arrangements and session segregation.

“Scotty we need more power er WIFI”
While the conference survey will prioritize on  what items will be most relevant to improve for the next Summit, one of the vocal suggestion at the BwtB was the never ending need for more WIFI.  We techies live on WIFI.

Who the heck is…
Leading the list for reasons to attend the Summit is to simply meet people we work with on IRC and other community channels.  A simple suggestion was made that we add IRC nicks in a nice big font to the front and back of the conference badges. 50% of the time you see the back of someone’s badge and don’t know who they are.

Traveling to the Fall Summit
For those traveling to the fall Summit from the North America, concerns over prohibitive travel costs was raised.  Determining a Summit location is made up of many different factors.  Cost of travel being one.    A Summit location effects attendance, whether it be in Portland or Hong Kong.  Balancing that cost can be tricky.   The planning committee investigations concluded that attendees will find that the travel rates will not be the feared prohibitive if they do some research and book early.

Driving Priorities
Several discussions evolved around the idea of how customer priorities are injected into each projects focus and features. Typically in a corporate development model such interests are captured and formulated into the development model through Product Owners (PO) or Product Managers (PM).  How does this map to the OpenStack model?  Which is easily generalized to how does this map to the open source world?

At the BwtB, several of the discussions converged on the notion of contribution.  Contribution either in the form of code, leadership or voice.  One company simply cannot pretend to make choices for resources in another company. At most you can find other resources from a  company which share a problem you are helping describe and therefore solve.

A familiar saying in the open source world is “scratch the itch”.  It is this saying which has driven open source developers for years.  If you find a need that nothing out there can meet, write a solution yourself or better yet voice the need to help find those who share in the need and write a solution together contributing in ways that leverage your experience and expertise or providing support to those who can contribute for you.

Big Vision
Also discussed at the BwtB was the notion of having the TC play more of a role across the various projects, for things like security and API versioning, aligning and setting direction across the groups. Citing the need for the TC (or someone at least) to give more cross project consideration for:
API compatibility and consistency
architectural consistency
security
Input from Users to guide our path

Align the Doc
Opinions voiced concerns that the documentation lags the implementations.  So how do we  make the OpenStack documentation more up-to-date and improve quality and timelines?  That was the question raised by attendees at the BwtB.  Offered suggestions included a requirement for documentation changes to be checked in concurrent with the code, rather than just setting a flag that the doc’s might be effected.

What comprises OpenStack?
A couple of tables discussed the current progress around the current Core/Integrated/Incubated framework with input on moving forward; people seem to prefer the kernel/drivers analogy. There is confusion regarding the new approach to core-integrated-incubation,  what the differences are, who gets seats on the TC, etc.  Early and continued discussions at Technical Committee and Board on this are important for next phases of the effort. It is important  to ensure that the TC and Board sign off on all steps with formal statements by the foundation when we arrive at any and all conclusions.

Interoperability
There is a lot of interop interest. Folks at the BwtB seemed to be mostly happy with the refstack approach. They voiced opinions about whether API-based interop or same-codebase interop is appropriate in various projects and for having verification teams for plug-ins.

Marketing OpenStack
Where does OpenStack as the data center operating system model go?  How to support that?  Marketing discussions ranged across several of the tables.  Including a conversation at one of the tables  on how to best explain OpenStack to CIO/IT Directors. Participants in the discussion felt that the video overviews available on the OpenStack website as well as the user stories presented at the Summit Keynotes were of great help.

Others pondered why FUD is generated by open source competition with a  lack of sense of those for who their competition really should be (proprietary software).

And others voiced concern over perceptions around OpenStack.  These perceptions include, complexity, talent shortages, security gaps and that it takes too many people to run OpenStack.  Such perceptions create a barrier to adoption.

Transparency
The Board at its February meeting, launch a committee to improve transparency and foster collaboration between the foundation members and members of the board, technical committee, user committee and other committees.  Members of the committee took the opportunity to discuss, at their tables, the committee ideas and efforts.  Everyone is all for transparency and seeking a balance between transparency and compromising the strategic position of the project was accepted as an important consideration. The ombudsman and staggered release were seen as valid solutions.

Attendees also voiced the importance for direct participation within project processes.  It is important that the TC and board to listen to what the project have to say.

Elections
The Board at its February meeting also launched an effort to improve the Individual member election process.  The board members engaged in this effort took the opportunity to gather feedback at the BwtB on the ideas and efforts underway.  Many were pleased that a schedule for implementation of changes is being set and were pleased with the efforts so far.

Conclusion
As you can see there was a wide range of topics raised and discussed.  Each of which could be worthy of a full writeup on its own. As a board we appreciate the input.  We will delve into the issues further and will use this input to guide the prioritization of our efforts.  So again thank you for your participation. We look forward to the next BwtB at the fall Summit.

Regards,

OpenStack Board of Directors

OpenStack Summit: Day 1

The OpenStack Summit started in San Diego today. Mark Collier announced during the kickoff meeting that there are over 1,300 people registered at the conference. As a result, lines for lunch were a bit slower than we wished. We’re coordinating solutions with the hotel to improve the situation. There will be also more power strips in the Developer’s Lounge area.

Lots of announcements today: Niki Acosta made a summary of all announcements for this first day. Worth mentioning also that Nimbula joined OpenStack.

Quantum's room was full all day, overcrowded some time.

The notes for each of the Design Summit’s sessions are listed below (note: there might be more etherpad listed on the official wiki page).

Documentation Track

Glance Track

Quantum Track

Nova Track

Swift Track

OpenStack Governance Elections Autumn 2012 Results

The OpenStack community has elected the Project Technical Leads. Here are the winners:

NOVA Project Technical Lead (1 position)

Winner: Vish Ishaya (only candidate)

KEYSTONE Project Technical Lead (1 position)

Winner: Joe Heck (only candidate)

HORIZON Project Technical Lead (1 position)

Winner: Gabriel Hurley  (only candidate)

SWIFT Project Technical Lead (1 position)

Winner: John Dickinson (only candidate)

GLANCE Project Technical Lead (1 position)

Winner: Brian Waldon (only candidate)

CINDER Project Technical Lead (1 position)

Winner: John Griffith (only candidate)

QUANTUM Project Technical Lead (1 position)

Winner: Dan Wendlandt (Official poll results)

OPENSTACK-COMMON Project Technical Lead (1 position)

Winner: Mark McLoughlin (only candidate)

Congratulations to all PTLs. They are automatically granted a 6-month seat on the OpenStack Technical Committee whose election process will start soon.

Back to top