Tag Archives: Board

OpenStack Core Online Forum, Oct 16 13:30 UTC / Oct 22 0100 UTC

Posted on by
Reply

Go Online!OpenStack Community, you are invited on an online discussion about OpenStack Core on October 16th at UTC 13:30 (8:30 am US Central) and October 22nd at UTC 0100 (8:00 pm US Central)

At the next OpenStack Foundation Board meeting, we will be setting a timeline for implementing an OpenStack Core Definition process that promotes a clear and implementation driven metric for deciding which projects should be considered “required.”  This is your chance to review and influence the process!

We’ll review the OpenStack Core Definition process (20 minutes) and then open up the channel for discussion using the IRC (#openstack-meeting) & Google Hangout on Air (link posted in IRC).

The forum will be coordinated through the IRC channel for links and questions.

Can’t make it?  The session was recorded > here!

Thinking about how to Implement OpenStack Core Definition

Posted on by
9

THIS POST IS #10 IN A SERIES ABOUT “WHAT IS CORE.”

Tied UpWe’ve had a number of community discussions (OSCON, SFO & SA-TX) around the process for OpenStack Core definition.  These have been animated and engaged discussions (video from SA-TX): my notes for them are below.

While the current thinking of a testing-based definition of Core adds pressure on expanding our test suite, it seems to pass the community’s fairness checks.

Overall, the discussions lead me to believe that we’re on the right track because the discussions jump from process to impacts.  It’s not too late!  We’re continuing to get community feedback.  So what’s next?

First…. Get involved: Upcoming Community Core Discussions

These discussions are expected to have online access via Google Hangout.  Watch Twitter when the event starts for a link.

Want to to discuss this in your meetup? Reach out to me or someone on the Board and we’ll be happy to find a way to connect with your local community!

What’s Next?  Implementation!

So far, the Core discussion has been about defining the process that we’ll use to determine what is core.  Assuming we move forward, the next step is to implement that process by selecting which tests are “must pass.”  That means we have to both figure out how to pick the tests and do the actual work of picking them.  I suspect we’ll also find testing gaps that will have developers scrambling in Ice House.

Here’s the possible (aggressive) timeline for implementation:

  • November: Approval of approach & timeline at next Board Meeting
  • January: Publish Timeline for Roll out (ideally, have usable definition for Havana)
  • March: Identify Havana must pass Tests (process to be determined)
  • April: Integration w/ OpenStack Foundation infrastructure

Obviously, there are a lot of details to work out!  I expect that we’ll have an interim process to select must-pass tests before we can have a full community driven methodology.

Notes from Previous Discussions (earlier notes):

  • There is still confusion around the idea that OpenStack Core requires using some of the project code.  This requirement helps ensure that people claiming to be OpenStack core have a reason to contribute, not just replicate the APIs.
  • It’s easy to overlook that we’re trying to define a process for defining core, not core itself.  We have spent a lot of time testing how individual projects may be effected based on possible outcomes.  In the end, we’ll need actual data.
  • There are some clear anti-goals in the process that we are not ready to discuss but will clearly going to become issues quickly.  They are:
    • Using the OpenStack name for projects that pass the API tests but don’t implement any OpenStack code.  (e.g.: an OpenStack Compatible mark)
    • Having speciality testing sets for flavors of OpenStack that are different than core.  (e.g.: OpenStack for Hosters, OpenStack Private Cloud, etc)
  • We need to be prepared that the list of “must pass” tests identifies a smaller core than is currently defined.  It’s possible that some projects will no longer be “core”
  • The idea that we’re going to use real data to recommend tests as must-pass is positive; however, the time it takes to collect the data may be frustrating.
  • People love to lobby for their favorite projects.  Gaps in testing may create problems.
  • We are about to put a lot of pressure on the testing efforts and that will require more investment and leadership from the Foundation.
  • Some people are not comfortable with self-reporting test compliance.   Overall, market pressure was considered enough to punish cheaters.
  • There is a perceived risk of confusion as we migrate between versions.  OpenStack Core for Havana seems to specific but there is concern that vendors may pass in one release and then skip re-certification.  Once again, market pressure seems to be an adequate answer.
  • It’s not clear if a project with only 1 must-pass test is a core project.  Likely, it would be considered core.  Ultimately, people seem to expect that the tests will define core instead of the project boundary.

What do you think?  I’d like to hear your opinions on this!

Taking OpenStack Core discussions to community

Posted on by
1

core flowTHIS POST IS #9 IN A SERIES ABOUT “WHAT IS CORE.”

We’ve been building up to a broad discussion about the OpenStack Core and I’d like to invite everyone in the OpenStack community to participate (review latest).

Alan Clark (Board Chairman) officially kicked off this open discussion with his post on the OpenStack blog last week.  And we’re trying to have face-to-face events for dialog like the Core meetup tonight in San Francisco.  Look for more to come!

Of course, this will also be a topic at the summit (Alan and I submitted two sessions about this).  The Board needs to move this forward in the November meeting, so NOW is the time to review and give us input.

We need better Gold Member criteria to help building OpenStack culture

Posted on by
6

bunny slippersDuring last OpenStack board meeting, we started a dialog that will be continued over the rest of the year.  It concerns how/if we should apply our criteria to measure the contributions of companies that are applying to become Gold members.

I believe that we should see many contribution “footprints” for companies in Foundation leadership positions.  These footprints do not have to be code in github: there are many visible ways to contribute to OpenStack including internal installs, delivered product, community meetups, open source support around code, service to the community through speaking and sponsoring and, of course, code too.

At this point in the OpenStack evolution, there is so much going on that it is easy to leave footprints because there are so many ways to engage.  Footprints are tangible evidence of community leadership and the currency of collaboration.  OpenStack thrives because we are committed to working together, being transparent in our actions and providing service to the project beyond our own needs.

I believe OpenStack Foundation’s new gold members will are great additions to our growing community; however, we need to be increasingly deliberate in accepting new Gold members to make sure that they have a history of demonstrating a culture of open source leadership and contribution.  

These applications deserve careful consideration for several reasons:

  1. there are a limited number of gold level positions (16 of the 24 are now occupied)
  2. there is no practical way to remove a gold member (but only 8 are elected to the board)
  3. there is a perception (by the applicants) that they gain additional credibility through gold membership
  4. gold and platinum members are the leaders of our community so everyone will models their behavior

It is important to remember that there is no limit or barrier (beyond $) to joining at the corporate sponsors level. So, being a gold member means that companies are seeking a broader leadership role in the project.

Over the next months, Simon Anderson (committee chair, Dreamhost) will be leading me and several other board members in an effort to refine of our Gold member review criteria.  I’ll post own list shortly and I’m interested in hearing from you about what type of “footprints” we should be considered in this process.

OpenStack Board Voting Starts! Three thoughts about the board and election

Posted on by
3

1/18 Note: I was re-elected! Thanks everyone for your support.

OpenStack Foundation members, I have three requests for you:

  1. vote (ballots went out by email already and expire on Friday)
  2. vote for me (details below)
  3. pick the board you want, not just the candidates.

And, of course, vote according to our code of conduct: “Members should not attempt to manipulate election results. Open debate is welcome, but vote trading, ballot stuffing and other forms of abuse are not acceptable.”

To vote, you must have been a member for 6 months. Going Mad Panda? Join right now so you can vote next time!

Even if you’re not a voter, you may find my comments useful in understanding OpenStack. Remember, these positions are my own: they do not reflect those of my employer (Dell).

Vote because it’s the strongest voice the community has about OpenStack governance

I’d strongly encourage you to commit code, come to the summit and participate in the lists and chats; however, voting is more. It shows measurable impact. It shows the vitality of the community.

OpenStack is exciting to me because it’s community driven.

I have been a strong and early leader in the community:

Vote for me because of my OpenStack Operations focus

My team at Dell has been laser focused on making OpenStack operable for over 2 years. My team acts like a lean start-up inside of Dell to get products out to market early.

We’ve worked with early operators and ground-breaking ecosystem partners (plus). We’ve helped many people get OpenStack running for real workloads. Consequently, I am highly accessible and accountable to a large number of users, operators and ecosystem vendors. Few other people in the OpenStack community have my breadth of exposure to real OpenStack deployments. My team and I have been dedicated, active participants in OpenStack long before Dell’s grand OpenStack strategy coalesced.

More importantly, I am committed to open source and open operations. The Apache 2 open source Crowbar project established the baseline (and served as the foundation) for other OpenStack deployment efforts. We don’t just talk about open source, we do open source: our team works in the open (my git account).

Vote for a board because diversity of views is important

OpenStack voting allows you to throw up to 8 votes to a single candidate. While you can put all your eggs into a single basket, I recommend considering a broader slate in voting.

We have an impressive and dedicated list of candidates who will do work for the community. I ask that you consider the board as a team. If you want operators, users, diversity, change, less corporate influence or any flavor of the above then think not just about the individual.

Why should I be part of your slate? I am not a blind cheerleader. I have voiced and driven community-focused positions about the board (dev cycle, grizzly >;; folsom, consensus).

One of my core activities has been to work on addressing community concerns about affinity voting. Gold and Platinum members have little incentive to address this issue. While I’d like to see faster action, it requires changing the by-laws. Any by-law changes need to be made carefully and they also require a vote of the electorate. If you want positive change, you need board members, like me, who are persistent and knowledgeable in board dynamics.

What have I done on the Board? Quite a bit…

It would be easy to get lost in a board of 24 members, but I have not. Armed with my previous board experience, I have been a vocal advocate for the community in board meetings without creating disruption or pulling us off topic.

Why re-elect me? For community & continuity

I am a strong and active board member and I work hard to represent all OpenStack constituents: developers, operators, users and ecosystem vendors.

Working on a board is a long-term exercise. Positions and actions I’ve taken today may take months to come to fruition. I would like the opportunity continue that work and see it through.

OSCBM Seeking Community Input for Long Board Meetings and Candlelight Coding Sessions

Posted on by
1

Happy OpenStack Foundation Launch Day! I’m a little breathless at OpenStack’s sponsored sprint to foundationhood but very proud to be part of the process (you can be too!).   Just looking at the numbers it’s clear that we’re building something important.

While it’s important that OpenStack is innovative, stable and useful cloud infrastructure, it’s equally important the project in collaborative developed.

Collaborative development makes it safe for so many diverse commercial interests to participate.  The Foundation, with a gold and platinum war chest,  is a reflection of the need for the project to remain both openly collaborative and commercially successful for our community.  We must ensure a level technology playing field while we work to ensure members of the community can be commercially successful while contributing.  This balance is one of our core challenges.

As an OpenStack Community Board Member (OSCBM), I want to hear what you think the OpenStack Foundation should be doing for OpenStack!

It is vital that I get input from the OpenStack community!  Unlike 2/3 of the Board, my seat is decided by the community and (re)elected by the community on an annual basis; consequently, it is my responsibility to voice Stackers’ interest, not my employer’s (Dell).

Frankly, the project is still hugely dominated by developers with users/operators only just gaining influence. The Foundation’s primary purpose is to help safe guard its independence. As a board member, my job today is to oversee building  up the critical infrastructure (like having a staff) to perform that mission.

Of course, you also need to know my priorities.

  1. Consensus governance helps ensure minority views get heard while we still act as a unified body.  Consensus includes formalized agendas, rules (aka Robert’s rules) , clarifying motions and simple actions to make it easier for the community to follow.
  2. More community integration in the form of work done in subcomittees that can bring in external voices and integration with technical and user committees.
  3. Make activities more consistent, visible and accessible.  While our actions are open, our practices (and audio bridges)  make it difficult for the community to follow along.  That includes faster turn around on minutes so that board actions are not subject to twitter extrapolation.

The board is still very young and I’m impressed with what we’ve accomplished so far.

OpenStack Board needs Consensus Governance

Posted on by
6

I am humbled by the community support for my election (I finished first in the results) and have been surprised to realize that one of my unlisted credentials, 5 years as Secretary of our local public Community Development Corporation, could also be an important asset. Dealing with Texas Open Government laws around parliamentary minutia such as open discussions, voting, minutes and agendas turns out to translate directly to open source governance (which affects everyone!).

I believe that the OpenStack Board should operate by Consensus rules.

Boards can choose to operate either by Consensus or Majority. A Consensus board typically passes all resolutions unanimously while a Majority board does not need agreement on decisions (see table below).

On first blush, majority process seems more efficient; unfortunately, split votes are divisive and polarizing. The consequence of split votes is the minority positions will seek longer debate, resort to back room politics and procedural overhead. This type of behavior would be destructive for our community.

A Consensus board, which only happens by implied agreement of the members and leadership, works to ensure that decisions can be supported by all the members. This does not mean that all the members agree with the board positions, hold-hands during meetings, or participate in Polynesian drum circles! It does mean that the board as a whole considers minority positions and their motivation before calling a vote. If there is too much difference in opinion, then the majority may defer voting or minority members may abstain from voting. One common aspect of Consensus boards is that members may appear to argue against their own positions to ensure that minority views have been represented.

While the consensus model takes discipline for our Directors, it also takes patience and cooperation from the community that we serve. Board actions may take longer or be less direct than members of the community desire.

I believe that committing to a Consensus board is essential for OpenStack because our board is large (24 members!), our community is diverse and the financial impacts to members are high. So far, I’m proud that we’ve been following that model and will try to ensure we maintain that tradition.

Post Script Table: Consensus vs. Majority Governance Snapshot

Consensus Majority
Voting Unanimous Split
Process Flexible Strict
Position in Discussions Ambiguous Polarized
Controversy Avoided / Postponed Forced / Decisive Wins
Community Encouraged Divided
Minority Interests Incorporated Excluded
Board Unity High Low