The OpenStack Blog

Author Archive

Chairman’s Corner: Great 2013 to even Greater 2014

2013 was a very active year for the OpenStack board of Directors – and as a personal note, a very enjoyable year.  When the Foundation launched in September of 2012, the critics were troubled that the Foundation would be led by such a large board of 24 members.  Although 24 is large for a board, I am happy to report that the benefits have far outweighed any drawbacks. A large board has allowed many viewpoints, opinions and expertise to be shared, considered and included as part of the decision process. It has served the Foundation well because the board members are focused on the community, are very active and committed to the success of the Foundation.

Over 2013 many new board initiatives were launched. Through these efforts, you can be assured that the Foundation’s finances, trademarks and other assets are under excellent care. The benefits of which will continue to manifest themselves throughout 2014 resulting in additional qualified members, OpenStack Summit travel assistance, aligned training efforts, user experience, adoption and case studies.

As a board we are excited by the prospects that 2014 brings. There are many areas where we want to grow and improve the Foundation.  Those of high importance are the ones we gather directly from the community. A few topics that I’d like to highlight, were gathered recapped at the Breakfast with the Board at the Hong Kong Summit.

Membership Growth

2013 has demonstrated tremendous community growth. Many of the people we talked to at the Summit are fairly new members of the community. We were very pleased to hear that their community experience has thus far been positive. They are encouraged by the tone of the community and the talented people whom are engaged in the effort.  2014 is the perfect point in time to help all members discover ways to contribute their talents and to develop collaborative connections across the community.

Recognition for Contribution

We all enjoy doing something that serves a purpose. Contributing to the OpenStack project provides many ways to do something meaningful. We have a very vibrant community with people who are very dedicated and passionate about what they do.  They give it their best because they’re passionate about the project’s future impact on technology. Finding ways to highlight people for what they do, we help the project to fulfill its purpose and help provide an environment where work has meaning.

Core Definition

OpenStack is enjoying tremendous growth with the number of new projects and programs. While this makes it exciting to be part of OpenStack development, for those that are new and those looking in from outside of the community, OpenStack could begin to look unfocused or fractured. Growth demonstrates the need to convey the message that the core and integrated components are mature and stable while the new projects bring exciting innovation. In our messaging, we’ll balance new features with stability and upgradeability of the code, while ensuring diversity of and innovation around non-core projects and plugins. Throughout 2013 working together the board and TC have been tackling this topic, working toward implementation in 2014.

Individual Director Elections

Over the past year, the board has been evaluating and looking for ways to improve the Individual Director’s election process. Given the dramatic growth of the community, the desire for diverse representation and community participation, the board has been analyzing potential options to find an alternative process that is preferred by the membership and that meets the legal requirements. Community feedback from Summit attendees clearly indicates a need for additional in-depth education prior to the board taking any form of action on this topic.

When a project has experienced as much early success as OpenStack has, it can be a tempting prediction to believe the momentum will slow down. But I’m not betting on it. We at the Foundation board are committed to building on our momentum this year, and these are just a few of the many fun initiatives that the board will tackle during 2014 to do so.  OpenStack is a fun project and a great community.  2013 was a great year. 2014 is going to be even more exciting!

 

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/

Ripple Effect

I enjoying hiking, and one trek I enjoy is a climb to over 10,000 feet within the Great Basin National Park to a small lake called Stella Lake.  Stella is very small and insignificant, if measured by size and depth. It sits at the foot of a small ancient glacier cirque sheltered by 13,000-foot Wheeler Peak.

Stella is cold and clear, fed by pure forested winter snows. Its remote location preserves its pristine environment. Its sheltered location creates an atmosphere of calm serenity. On many of my visits, the air has been so calm the surface of Stella was as a mirror, reflecting the beauty of the granite cliffs, evergreen trees, clean blue skies, and cottony white clouds off its clear glassy surface. The toss of a small stone into such still waters ripples across the entire lake reaching the farthest shores, catching the silver sparkles of the sun in its wake.

The ripple effect.  Where a seemingly localized action transfers to great distances.

With all that is being accomplished within the OpenStack project, we should not forget about the ripple effect.  This effect occurs daily through the associated commercial and community open source projects tied into the project. An OpenStack release, such as Grizzly, is like a toss of a stone into the waters of the cloud ecosystem.

Many community projects and commercial ventures closely follow the OpenStack project through the life of each release.  Tracking changes on a daily basis they see the code, learn from it, adapt it, and enhance it.  Processes that not only ripple out to the Cloud ecosystem but ripple back into the OpenStack project as well creating a mutually beneficial relationship.

Community open source projects check out the changes, build OpenStack within their own projects, run functional and unit tests for each component, and put the code through its paces.  Their  development processes included additional code reviews, component integration and testing tailored to their community or organization projects.  Through their processes additional bugs are quickly found and fixed.  Through their efforts OpenStack is distributed as a part of their projects. Through their efforts OpenStack receives the ripple effect of return contributions through reported bugs, patches, and feature enhancements.

Commercial programs conduct similar testing and review steps while typically adding service and support for a variety of platforms, middleware, and applications. Their contributions back to the OpenStack project provide increased quality and more easily integrated software.  Attributes that keep getting better with each OpenStack release.

As you can see the ripple effect not only extends OpenStack into a worldwide distribution but into a worldwide community.  A community of vastly growing knowledge and ideas.  Quite simply, the ripple effect helps make open source software better, faster.

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.

AlanClark

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.

Back to top