The OpenStack Blog

Category: OpenStack Update

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


Lessons, Learning, and Long Views for Internship Programs

In January 2013 the OpenStack project welcomed aboard three interns and excitedly assigned them to work on fairly complex projects in our first attempt at an organized project-level internship program. The OpenStack Foundation participated as one of the organizations with the GNOME Outreach Program for Women and learned quite a few lessons during the six months internship period.

By February, two of the interns had learned the tough lesson of what happens when coordinated work efforts move at a fast pace. For example, Laura Alves, an API documentation intern had a patch with a manually created WADL for the Networking project nearly completed. She started requesting reviews from the core developers. We soon discovered that the devs were working on an automated method for creating the WADL. It certainly took some quick communication and coordination to make sure her work wasn’t wasted. Her efforts certainly weren’t wasted but it also hasn’t landed quite yet either. Lesson learned: internship projects are difficult to scope and it’s nearly impossible to set aside tasks in a reserve area just for interns.

Still more lessons learned were that the timing of code freeze dates landing prior to the internship’s completion made for a steep on ramp for new interns with early deadlines. We also found that interns can contribute so much right away with their fresh perspective — and they created such valuable blog entries for newcomers, like Logging and debugging in OpenStack by Victoria Martínez de la Cruz,  so they’ll be helping more newcomers for months.  We pulled all our lessons learned together for a “What Everyone Should Know About OpenStack Internships” panel session at the Summit in Portland.

One of the takeaways from the Summit was to learn more about mentoring from Katy Dickinson, and the blog at MentorCloud where she is Vice President has been very valuable to learn from as we continue to shape our plans for interns wanting to learn and contribute to OpenStack. Katy attended our brainstorming session at the Summit and gave us very useful suggestions. We surveyed outgoing interns and are working on a plan to coordinate early and often to identify and promote natural mentors in the OpenStack community.

The more you look for internships and mentors in OpenStack, the more you’ll find. Cisco has interns working on OpenStack projects each summer. One OpenStack intern, Emilien Macchi, at StackOps went on to do a graduate part-time internship at eNovance. Rackspace has interns working on multiple OpenStack projects.

The Foundation is continuing the involvement in the Outreach Program for Women also in the northern hemisphere’s summer edition: Terri Yu started working on the Ceilometer project with Juilan Danjou at the end of May: be sure to welcome her! Look for more opportunities to connect the dots with interns and mentors in the coming months. If you have funds for travel so interns and mentors can meet each other in person, let Stefano Maffuli know. If you have a great intern story to tell, please let us all know.

Havana: An Enterprise IT Perspective

Intel IT has been working with OpenStack in our labs starting with Cactus, our first deployments into production were with Diablo, which we quickly moved forward to Essex and have been running production apps on this since the summer of 2012.  Since then we have been getting deeper and deeper into OpenStack, and recently had 8 of our Intel IT engineers approved to start contributing to the codebase, and have done our first contributions in the last few months.  May sound simple, but complex for a large enterprise shop like ours – and we are super jazzed to start contributing more and more…  looking forward to working as part of the community with more breadth and depth now thanks for having us :)

While we are in the midst of our Grizzly rollout, we are getting involved in the Havana specifics, and I wanted to share some of the key features we are excited about and share some of the use cases these help us with.

Our overall goal is to turn all of our data center into a software exposed environment, virtual machines, physical machines, networking, storage, and all of the components that make our complex and simple apps work at scale.  A number of the Havana features are really going to help make some big steps for us all into this level of capabilities:

At the foundation level, since we run traditional enterprise workloads along with new cloud-aware apps it is very important that resilient infrastructure solutions continue to improve, for instance live migration and restart on failure capabilities which are both supported by boot from volume block storage, and improvements in the orchestration code.  We also intend to use OpenStack to control physical nodes, therefore metal as a service work is increasingly important to us; our intent is to control our VMM sand physical nodes with one scheduler and one set of APIs/CLIs.

A lot of our work is happening at the higher levels of OpenStack, as we enable more complex applications and cloud-aware apps we need strong orchestration and automation for all of the resources OpenStack controls..  for instance we need auto-scaling, ability to deploy many machines in complex collections, controlling various networking asoects from IPs to firewalls all as part of the rollout of a single application.  Advances in HEAT to get us to a production level for our more advanced use cases are vital, as well as the improvements happening with LBaaS and OpenStack Networks.  We are also excited about the introduction of the service chaining concept which will let us declare our application flow and have OpenStack implement it from Internet all the way to the backend DBs.

As a large IT shop we also have to run our capacity like a supply chain so we need quotas and showback of resources for all of the services we expose to ensure the right usage behaviors while still allowing for rapid elasticity. Ceilometer across all resource types with granularity for users and projects get us to where we need for managing our capacity real time and with proper buffer capacity before new physical hardware lands, in turn allowing us to appear infinite in resources to our end users.

Speaking for the entire Intel IT Open Cloud team… the fast pace of the OpenStack community is why we decided to run this solution and contribute to it, we look forward to even more after Havana which will take our open cloud platform further out onto the cutting edge.  Don’t take a rest yet, we have a marathon we are on…. Hope to see you in November.

The next steps for OpenStack Activity Board

The interest around OpenStack Activity Board launched only two months ago is rapidly becoming the self-service place to find details about the activity of OpenStack development. There are still some known bugs to fix and while those are solved it’s time to start thinking about the future.

Today the Activity Board is capable of answering quantitative questions on the Dash like: how fast are we committing code to OpenStack? How many people are involved in fixing bugs and adding features to projects, like OpenStack Compute or Ceilometer? How much traffic and how many voices are active on the mailing lists? It can also give Insights on the context of any action of the community: who (people or company) is fixing bugs or committing code related to OpenStack Block Storage? Who’s contributed something (code or bug reports) for the first time or who’s doing ‘stuff’ in the past 30 days?  The insights can be useful for new members of the community to identify, for example, the most knowledgeable people in a particular area of the code. Or for a potential customer to identify the companies with most expertise in areas crucial for them. Since Activity Board launched we’ve received also comments and requests for new reports from project managers, developers and marketing managers. Keep them coming: the more feedback we get the more useful the tool can be.  We are thinking of ways to include more sources of data. For example, now the page for OpenStack Object Storage shows the list of recent bugs, reviews, milestones and branches, links to core repository but we can add links to the recently relevant questions on Ask OpenStack and to relevant documentation pages and even show there information about people and companies active on reviews, bug fixing and code contributions. A page like that could well become one of the main source of relevant, always up to date, information about any project.

The Activity Board project is a young project but it is growing fast: there are many ways to contribute to OpenStack Activity Board, the simplest of which are to join the discussions tagged [Metrics] and add your ideas to the wishilist. If you have special requests, data that you would like to see tracked and reports you’re interested in let us know.

New Foundation Gold Members & Corporate Sponsors

The OpenStack Foundation was thrilled to add two new Gold Members and 13 corporate sponsors so far this year to the already impressive list of companies who are supporting the Foundation and driving innovation on the platform.    Ericsson and Juniper Networks won the OpenStack Board’s approval at the April board meeting and joined the Foundation as Gold members.  To learn more about these companies and their OpenStack initiatives please visit and

We’ve also seen amazing support in Corporate Sponsorship and we want to share the impressive list of recent additions.

The diversity in technologies and geographic location of these new additions to the ecosystem reflects the growth of OpenStack and its footprint worldwide.  We are looking forward to enjoying each these companies’ unique contributions going forward!

Enter OpenStack’s T-shirt Design Contest!


Show us your creative talent & submit an original design for our
2013 OpenStack T-shirt Design Contest!

  • Winning design will be announced the last week in August 2013
  • Original artwork will be showcased on T-shirts given out at LinuxCon Cloud Open in New Orleans, September 16-18, 2013 as well as future events worldwide
  • Creator of the winning design will receive attribution on the T-shirt and public recognition on OpenStack’s website
  • Submissions will be accepted through August 1, 2013
  • Email submissions to [email protected] -  Subject: OpenStack T-Shirt Contest

For reference, view current OpenStack T-shirt designs HERE.

Submitting an entry:

  • Please make file Actual Size in inches (up to 10″ x 10″)
  • Digital art entries only; high-resolution (300 dpi) layered .psd/.eps/.tif (Photoshop) file or .ai/.eps Vector Files (Illustrator) are preferred
  • Do NOT send Microsoft Office files or Low- Resolution Files
  • There should be no embedded bitmap images (jpg, tif, bmp)
  • Colors should be spot with no half-tones
  • Convert and group all fonts to outlines
  • Please notate the preferred T-shirt color for printing
  • Please provide a jpg/png/screenshot of the completed artwork to act as a proof for your submission files.
  • Email submissions to [email protected] Subject: OpenStack T-Shirt Contest
  • Submissions will be accepted through August 1, 2013
  • Note: If you have any questions about how to properly submit your file, please contact email questions to [email protected] Subject: T-Shirt Contest Help


  • The design must be your own original, unpublished work and must not include any third-party logos or copyrighted material; by entering the competition, you agree that your submission is your own work
  • Design should be one that appeals to the majority of the OpenStack developer community
  • Deign may include line art, text, and photographs
  • Your design is for the front of the shirt and may encompass an area up to 10″ x 10″ (inches)
  • Design may use a maximum of three colors

The Fine Print

  • Maximum of one entry per person.
  • Must be original art. Content found on the internet rarely has the resolution needed for print and is often considered unlawful to use without permission
  • Submissions will be screened by the OpenStack Foundation for merit and feasibility
  • The OpenStack Foundation marketing staff will select the contest winner
  • The OpenStack Foundation reserves the right to make changes to the winning design before printing, including changes in image size or ink color or t-shirt color.
  • By submitting your design, you grant permission for your design to be used by the OpenStack Foundation including, but not limited to, the OpenStack website, the 2013 OpenStack Cloud Open T-shirt, and future marketing materials
  • The OpenStack Foundation reserves the right to final decision
  • The creator of the winning design will receive attribution on the T-shirt and public recognition on the OpenStack website

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
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.

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.

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.

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.

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.


OpenStack Board of Directors

A Pretty Good Place to Be

One of the best things about my work with OpenStack is the excitement I get when I envision the impact the work we do here today will have on the IT departments of the (very near) future.

Imagine a stay in a hospital, where instead of of nurses and med techs coming in every four hours around the clock to monitor your vital signs, a small monitoring device with specific sensors sends a steady stream of medical information to a central monitoring station. Software at the station not only looks for large anomalies, but also innocuous patterns that could indicate something serious.

Or imagine that kind of medical data being delivered to a central monitor when the patient is in their home. Or at work.

Fill a city with climate and environmental sensors, like noise and light levels, and use those sensors to identify emergencies before someone can dial a phone or long-term problems about the health of a particular neighborhood.

Put some sensors in a farm field in a developing country, and let farmers use the gathered data to know exactly how much water and nutrients to use for different parts of the field. For pennies a sensor, the yield of the field is maximized to help support a family for another year and maybe bring a little extra to the market.

A train car that knows exactly where it is at any given moment, cutting down on waste and unexpected routings.

A smart home that can control temperature, ambient light, and even alert a parent when a toddler is opening a cabinet they are not supposed to be in.

These are all just a very few examples of what the media calls the Internet of Things, either very real or in development as you read this. If you look an an object and imagine what that object could do if it were connected to the Internet, you can think of cool new applications on your own.

“Internet of Things” is a romantic notion. It’s not like web servers and file servers were animate objects all this time. But  whatever you call it, this new interconnected network of everyday objects will greatly impact people all of the world.

You can be sure that entrepreneurs are thinking of creative new ways to plug more devices into the Internet of Things, and all of them will need the same thing: a safe, secure platform on which they can store the data they will gather and analyze it to deliver the key services they will provide. If that platform is highly configurable and open, so much the better to mesh the platform to their needs.

One of the many applications of OpenStack technology will be to build that platform, and be a part of a world that will talk to us and tell us how to take better care of ourselves.

And that’s a pretty good place to be.


Project Incubation Process Update is Underway

If you take a moment to view the different projects, committees and work groups that are currently underway within the OpenStack project, 2013 is looking to be a very exciting year for cloud computing.  I could easily write an entire dissertation about the accomplishments the community will make this year now that the OpenStack Foundation is launched and the Technical Committee (TC) and OpenStack Board are formed. For this update, I’ll spare you the lengthy dissertation and focus on our effort to improve the existing open source incubation process for OpenStack. For ease, let’s call the incubation process update the IncUp effort.

The incubation process provides new projects the oversight, guidance and time needed to grow and mature.  The goal is to assure projects meet a high standard of usefulness and quality as they mature and become an integral part of OpenStack. The current process has served OpenStack well. Through that process the project has developed several key technologies that are core to OpenStack.

I read a funny quote  attributed to Mark Twain, “A man who carries a cat by the tail learns something  he can learn in no other way.”   The TC has done a wonderful job with the current incubation process, with lessons learned and experience gained. With formally outlined roles and responsibilities by the Foundation bylaws the TC and Board have increased responsibility to ensure the incubation process is a success.

The goal of the OpenStack Foundation is to serve developers, users, and the entire ecosystem by providing a set of shared resources to grow the footprint of public and private OpenStack clouds, enable technology vendors targeting the platform and assist developers in producing the best cloud software in the industry.

To better meet this challenge, the Technical Committee (TC) and OpenStack Board have kicked off the IncUp effort to update the current incubator process.  The effort is significant to all of us within the community because it’s a fundamental part of how a project’s destiny is determined.  A clearly defined incubation process influences the way we work together, facilitates growth, and ensures success through fair equitable and open processes.

Gandhi said, “be the change that you wish to see in the world.” Which profoundly articulates how much of IncUp we’ve already accomplished through our current state of “being.” The launch of the Foundation established an independent, vendor neutral, secure and safe environment for OpenStack technologies to grow.  Today, members of the board and the technical committee work together for the proper advancement of OpenStack technologies. And support from our members, sponsors, community and dedicated resources foretell the many projects underway within the OpenStack Foundation are already positioned to succeed.

Over the past several weeks, the IncUp committee has spent much time ensuring we understand the current incubation process and the issues at hand. Many questions were raised and we’re listening closely to feedback from project leads. The information we’re collecting is helping us rapidly paint the improved process.  Once that step is complete we will quickly draft the updated process, conduct reviews and prepare to roll out the updates.

Much of the fun of open source is the feeling of being part of and contributing to a recognized, successful project.  The continued purpose of the IncUp effort is to help ensure that projects receive the focus, visibility and resources needed to be successful via a fair, equitable and open process.  A process that ensures open source projects support the mission of the Foundation and the purpose of OpenStack.

I agree with Mark Collier when he said one day cloud computing will power our global economy.  I believe this can only be accomplished with the mindset to make technology collaborative, affordable and available to all. OpenStack is an exciting place to be for 2013.  The IncUp effort is one of many great things happening this year. Be sure to join a project, committee or work group to be a part of the future of cloud computing.

Introducing the User Committee

As the number of production OpenStack deployments increase and more ecosystem partners add support for OpenStack clouds, it becomes increasingly important that the communities building services around OpenStack guide and influence the product evolution.

When the OpenStack Foundation was launched in 2012, there were two initial structures created. The management board provides strategic and financial oversight of Foundation resources and staff. The technical committee defines and stewards the technical direction of OpenStack software development. We are now establishing the user committee whose role is to represent the needs of the diverse range of OpenStack users.

The user committee mission is to

  • Consolidate user requirements and present these to the management board and technical committee
  • Provide guidance for the development teams where user feedback is requested
  • Track OpenStack deployments and usage, helping to share user stories and experiences
  • Work with the user groups worldwide to keep the OpenStack community vibrant and informed

The structure of the user committee is currently being defined. Tim Bell, Ryan Lane and J-C Martin have been nominated by the management board and technical committee to work with the community and determine the by-laws and scope. This process is ongoing through the foundation mailing list and points to review document. Amongst the areas of discussion are the definition and representation model of the wide spectrum of users in different industry segments ranging from end-users submitting work to an OpenStack cloud through ecosystem partners using the APIs to provide additional services to those deploying and operating clouds in production. It is also planned to expand the committee further to cover both industry segments and user group representation along with running a user survey with the goal to present the results at the next summit.

For those of you who would like to help, please look at the points to review document and post your thoughts to the OpenStack foundation mailing list.

Back to top