The OpenStack Blog

Category: Uncategorized

Welcome new Gold Members Aptira, Hitachi, and Huawei!

The OpenStack Board of Directors approved Aptira, Hitachi and Huawei as Gold Members of the OpenStack Foundation. The companies are based in Australia/India, Japan and China respectively, and range from a startup to established, multinational corporations.

The timing couldn’t be better in my view, given that we are having our first ever Summit in Asia this week with attendees from 50 countries, including many from Australia, Japan, India, and China. As OpenStack adoption continues to accelerate around the globe, I am excited to welcome these new companies to the Gold Member ranks.

Some Background on the new members:

Aptira is a services business that focuses primarily on consulting, integration and training for OpenStack. Aptira has been instrumental in building the OpenStack community in Australia and India by organizing user groups, promotional activities and offering training courses. The company open sourced much of its training material and is collaborating across the community on broader education efforts.

Hitachi’s JP1 systems management solution supports OpenStack, and they’ve contributed support for their Hitachi Unified Storage platform for OpenStack Block Storage. The company also sponsors community building efforts in Japan, including an OpenStack event happening in Tokyo, February 2014.

Huawei is a top 20 OpenStack contributor that has contributed a Block Storage driver to support Huawei storage solutions, as well as made broader contributions to OpenStack documentation and testing systems. Huawei has supported community building efforts in China, including organizing meet ups and conferences, publishing whitepapers and blogs, and sponsoring and promoting the Summit this week.

Now let’s give each of the contributors from these companies a proper stacker welcome in Hong Kong this week!



OpenStack Launches Training Marketplace

Screen Shot 2013-09-16 at 10.37.09 AM

Today the OpenStack Foundation has launched a new Training Marketplace, making it easier to discover and participate in training courses offered by technology providers in the OpenStack ecosystem. Aptira, hastexo, The Linux Foundation, Mirantis, Morphlabs, Piston, Rackspace, Red Hat, SUSE and SwiftStack are the first companies to have courses available in the Marketplace, with the goal of growing the OpenStack talent pool and accelerating the availability of OpenStack training courses worldwide.

To find an OpenStack training course from the ecosystem of providers, visit
OpenStack expertise continues to pay off, with OpenStack jobs consistently paying higher wages and employers doubling the number of job postings over the past year.  The ecosystem has quickly responded to help developers and operators gain these valuable skills, with dozens of courses across 10 countries and 25 cities included in the Marketplace at launch. Future demand for OpenStack skills is only expected to grow, with the BSA Global Cloud Scorecard predicting that 14 million cloud jobs will be created by 2015.

OpenStack Jobs Pay

OpenStack Jobs Pay

“The goal of the Foundation is to eliminate barriers to OpenStack adoption, create more OpenStack experts and ensure that OpenStack has a positive impact on the careers of our community members,” said Jonathan Bryce, executive director of the OpenStack Foundation. “We want to grow the community, accelerate the availability of training programs worldwide and help close the OpenStack job gap.”

In order to offer courses in the Training Marketplace, companies must meet requirements set by the Foundation, with the primary purpose of the course being to contribute to, operate or build applications for an OpenStack cloud. The training curriculum should provide a strong understanding of the OpenStack core projects based on a current version of the software, as well as cover community governance and contribution processes.

In addition to paid and free training courses by companies in the OpenStack ecosystem, there are many community efforts to produce helpful documentation, how-to information and new Operations and Security guide books. There are also many educational sessions and hands-on workshops scheduled for the next OpenStack Summit, November 5-8, in Hong Kong. Workshops from previous Summits are available to view online.

Does your company offer training for OpenStack?  Contact us with details:

Participate in the OpenStack User Survey by September 30!

We’re kicking off the second round of the OpenStack User Survey this month! You may remember before the April Summit we helped the User Committee run a survey to aggregate OpenStack deployments and share the results.

The first User Survey provided great insight to the types of deployments and technology decisions made by the OpenStack community. We were able to catalogue 230 unique deployments – you can see the results presented by the User Committee at the last Summit. Another huge benefit was the ability to uncover new users willing to talk about their OpenStack deployments, which can be found at

If you are an OpenStack user or have customers with OpenStack deployments, please take a few minutes to respond to our User Survey or pass it along to your network. The goals of the survey are to better define the OpenStack user community and requirements, facilitate engagement and communication among the user community, and uncover new use cases or OpenStack users who might be willing to tell their stories publicly.

Below you’ll find a link and instructions to complete the User Survey by September 30, 2013 at 23:00 UTC. If you already completed the survey earlier in 2013, no need to start from scratch. You simply need to log back in to update your Deployment Profile, as well as take the opportunity to provide any additional input.

Take the Survey:

All the information provided is confidential and will only be presented in aggregate unless the user consents to making it public. Aggregate responses will be shared with the OpenStack Board, Technical Committee and community at large to help shape the roadmap and share useful information regarding operational decisions.

You can also help us by promoting the survey so we can secure as much participation as possible, for example by retweeting the OpenStack handle.

Remember you can hear directly from users and see the aggregate survey findings by attending the next OpenStack Summit, November 5-8, in Hong Kong.

Thank you for your support!

Open Mic Spotlight: Flavio Percoco

Screen Shot 2013-09-12 at 8.40.46 AMThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful. Each week, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun. 

Flavio spends most of his time hacking on storage (Glance [core member], Cinder, Swift) and messaging (Marconi [core member]) modules. He has both Italian and Venezuelan roots, and is currently based in Italy where he works remotely for Red Hat. Flavio is also an actively open-source contributor and part of Mongodb Masters group.

Prior to Red Hat, Flavio worked on Big Data oriented applications, search engines and message systems. He was also an active member of Gnome’s a11y team where he contributed to Orca and created MouseTrap, a head-tracker application. Outside Red Hat, he likes to take pictures, swim, travel, hang around with family and friends and whatever seems interesting. You can follow him on Twitter at @flaper87.

1. What is your go-to beverage or snack while coding? 

Coffee and Gummy Bears. Here’s proof:

2. What behavior has helped you get the furthest as a developer? 

“Be humble about the things you know and fearless about the things you don’t know… And keep going.” I always remind myself this.

Computer Science is one of those careers where people never stop learning. It keeps evolving every second, there are always new things to learn, share or do.

I consider myself a very passioned developer and I’m always looking for new things to learn and share. Whenever I get the chance, I dig deeper on the things I like the most and I’m always looking forward to share everything I know with other people.

This way of thinking has taught me that knowledge is worthless if you don’t know how share it.

3. Why did you get into computer engineering?

I’m not one of those who started playing with computers since he was 3 years old. I spent my childhood playing outside my house rather than inside it. I started playing with computers – and I mean programming - when I was almost out of high school – or was I out already? mmh – and I completely fell in love with it. My first distro was RHEL and after it I jumped through a whole bunch of different distros.

My other options besides computer engineering were: Physics, Medicine or Psychology but I’m programmatically lazy so, here I am. I still want to study Physics, though.

4. What are your tips or tricks for surviving jet lag or long conferences?

Trust your clock, it’s always right (unless you forget to change it to the local time).

Don’t think about how tired or hungry you are because you’re not. If your clock says 12:00 then it is time for lunch, if it says 20:00 it’s time to have dinner and if it says 2:00 then you can be tired and go to bed.

I call that: “Biology by approximation”

5. Not counting the obvious (your colleagues or close former colleagues), who have you worked with closely, built a relationship with or learned the most from in the community? Why? 

Without any specific order:

Doug Hellman: No matter how or with regard to what, I always learn something new from him. Email threads, reviews or code, it doesn’t matter, he’s always teaching me something.

Devananda van der Veen: When we met at the last Europython, we not just talked about technology but also about Philosophy and Buddhism. I really enjoyed our conversations and learned at lot from them.

The whole Marconi team: Those guys rock. We’ve been working very closely since the project started. We’ve made calls, meetings and hung around on IRC. All this time, we’ve shared and learned from each other. Also, I’d dare to say that Marconi’s irc channel is the funniest throughout OpenStack.


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


Voting is Open – Help Choose Who Will Speak at the Next Summit!

Which speakers would you like to see at the next Summit?  It’s time to vote!

We’ve received a record breaking 600+ speaking submissions for the Summit in Hong Kong – more than double the quantity of submissions received for the Portland Summit!

Now it’s time to vote!  We’d like your help shaping the agenda for the next OpenStack Summit, November 5-8 in Hong Kong, by rating the submissions you’d like to see.  We’ve made all 600+ submissions public for your input.  You have until Sunday, August 25 at 22:00 UTC to vote up your favorites.


Our voting interface is designed for easy use via mobile devices so you can continue selecting your favorites when you’re on the go.  Please note that you need to create login credentials in order to access the voting system.

While the Design Summit and more technical content will run Tuesday – Friday, the General Session track and keynote presentations will be Tuesday and Wednesday. We’re hoping to have the agenda locked and published by the end of September, but in the meantime you can see a preview of the agenda here.

A big thank you to our Summit sponsors for their continued support of the OpenStack community. See our current list of sponsors here.  If you are interested in sponsoring the summit as well, it’s not too late. Please email no later than September 20.

Early Bird Registration closes October 4, so register now for discounted rates.   We also encourage you to book your travel now – hotel rooms are going fast.  Our block at the SkyCity Marriot has already sold out, but we still have room block availablility at Novotel and Regal, near Asia World-Expo where the Summit will take place.

Only three short months before we kick off the next OpenStack Summit, and we look forward to seeing you in Hong Kong!

OpenStack Celebrates Three Years!

Screen Shot 2013-07-19 at 10.05.09 AM

OpenStack is no one person or company or idea or line of code. It derives its strength from the collective community. No matter when you joined or what role you play, you have the ability to shape the future of OpenStack and computing.

In three short years since the community was established, OpenStack has truly become the center of cloud innovation, attracting hundreds of talented developers, brand-name users, and support from major industry leaders. This calls for a big toast to you, the OpenStack community!

We invite you all to join the party and celebrate 3 awesome years of stacking:

  • Check out OpenStack’s Birthday Page featuring the latest stats, infographic and a web badge to download
  • Visit the OpenStack booth at OSCON, July 22-26, in Portland, OR and attend the birthday party, Wednesday, July 24
  • Attend your local birthday party, more than 40 are taking place around the world this week!
  • Learn about the contributors who make OpenStack successful through the #OpenStack #OpenMic series
  • Join the conversation on Twitter today using the hashtag #OpenStack3Bday

We’d also like to share some great perspectives from community leaders about the significance of three years for OpenStack, and where the community is headed:

Happy 3rd birthday to the OpenStack Community!

Infrastructure Bootcamp

Recently the Project Infrastructure team hosted a two-day “bootcamp”
for people who are interested in contributing to the Project
Infrastructure.  The OpenStack project is so large, and continuing to
grow, that creating and operating the developer infrastructure for the
project itself is a unique challenge.  Because OpenStack receives code
contributions from more than 600 developers in a release cycle, and
merges as many as 200 changes per day, we are at the cutting edge of
distributed development and testing.

The project infrastructure covers a wide range of tools and services
used by the project, including code review, testing, and
collaboration.  The design and operation of these systems is managed
under the Infrastructure Program which is overseen by the TC just like
the rest of the OpenStack project.  And like any other OpenStack
program, our team is open and we welcome contributions from anyone.

Managing the infrastructure for a project of this scale is a lot of
work, but it is uniquely rewarding because it affects every OpenStack
project and affords interactions with all of the developers.  We heard
a lot of interest from persons and companies who wanted to contribute,
so we held the bootcamp to get anyone who was interested in
contributing together in a room with the current core team of
infrastructure developers.

OpenStack Infrastructure Bootcamp kicks off

OpenStack Infrastructure Bootcamp kicks off
Photo: Elizabeth Krumbach, CC-BY 2.0

Day one saw us all together and discussing how contributions are
accepted, how the team operates, and how new members can expect to
become core members in the future.  We discussed each major system at
a high level, and worked out how all of the systems interact with each

In the evening, we all got together for dinner and spent several
enjoyable hours talking about how we could improve the system, and
generally getting to know each other.

On day two, we dove deeper into some topics of particular interest to
attendees, and generally had a less structured approach where people
who shared interest in an area got together and discussed it in depth.

I think everyone who attended got a lot out of the event, and we’re
already seeing significant new contributions as a result.  I hope that
in several months more time we will have new core members on our
team.  I also think this is a good model for other programs in
OpenStack who want to quickly bring new contributors up to speed.

I’d like to thank Monty Taylor for organizing the event, the rest of
the core contributors (or “coremudgeons”) for talking about what we do
for two days straight, and Hewlett-Packard and the OpenStack
Foundation for sponsoring the event.

Some reactions from others who attended:

Open Mic Spotlight: Aaron Rosen

Aaron RosenThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful as we celebrate the third birthday of the project. Each day in July, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun.  

Aaron Rosen currently works on OpenStack for Nicira/VMware. Most of his time is spent working on the Network Side (Neutron), though he also dabbles in the compute side (Nova). He’s most interested in networks, especially virtual ones. He graduated with a Masters in Computer Engineering from Clemson University in 2012, and joined Nicira right out of school. 

1. What’s the most critical feature you think cloud software needs to be widely adopted over the next year?

I would have to say Software Defined Networking (SDN). The network has been one of the major bottlenecks in the time that it takes to provision a new application. In addition, using traditional networking techniques such as VLANs are hard to manage and have scaling limitations. With SDN, it enables networks to be self service entities where users can provision networks, routers, load balancers, firewalls, etc. on demand via a self service portal, and deploy their application immediately. Previously, one would have to submit a help ticket and wait for the IT department to process it (some days or weeks later). In my opinion, this is one of the most important features of cloud and what the OpenStack Neutron (formerly Quantum) project aims to solve.

2. What is the most important contribution you’ve made that will make OpenStack users happy?

My most important contribution that I’ve made to OpenStack was the Security Group API implementation in Neutron. In Folsom, if one wanted to use security groups, one would need to use Nova’s security group implementation, which had a few limitations that we wanted to fix. The first limitation was that Nova security groups implementation did not work in conjunction with overlapping IP addresses. Since the point of Neutron was to let people have self-service control over their networking and addressing, this meant it was hard to use security groups with Neutron at all.  In addition, Nova’s security groups did not support egress filtering unless a tenant enforced this themselves within the instance.

Egress filtering allows tenants to enforce, which end hosts and protocols their instances are able to initiate communication with, which is useful if one wants to lock down who their instances can communicate with.

The last part of the security group work was to implement the ability for Nova to proxy its security group calls to Neutron. This is important because it allows one to create an instance via Nova and specific security groups in Neutron in addition to allowing existing scripts/tools to continue to work and allows Nova’s EC2 security group implementation to work with quantum.

3. Describe an interesting OpenStack deployment that you were part of, and why others ought to know about it. What made that project work? Tick?

At VMware we have an internal OpenStack cloud (~200 servers) that we use to host test/dev workloads and labs to demo our software to customers in addition to dogfooding our software on before it gets to customers. The interesting part of this deployment is that all of our developers use this as their primary development environment.

When I first joined the company, everyone was issued a server to run their VMs on that they were responsible for maintaining and running backups. Now, over a year+ since this cloud has been deployed, nearly every developer has returned their server that previously sat under their desk as it was no longer needed. I think what makes this deployment work is the dedicated and talented team that is tasked with maintaining this cloud and the open mindedness that its users have in the power that cloud provides. I’d have to say this is probably one of the most sophisticated cloud deployments out there powered by OpenStack with Nicira NVP for SDN, running both KVM and ESX hypervisors. I’m also proud to admit that we successfully upgraded this cloud from OpenStack Folsom to Grizzly a few months back!

4. What other open source projects do you think work well with OpenStack, and why?

  • Python! — Nuff said (Everything in OpenStack is written in Python.)
  • Open vSwitch — A programmable software virtual switch that most neutron plugins leverage to implement SDN.
  • Gerrit ( – There are a few things I don’t like about it, but all in all I think it works well in order to keep track and review the massive amount of patches against OpenStack.

5. How would you suggest to someone that they should pick OpenStack for deployment? What is the most compelling argument for OpenStack in your mind?

The compelling arguments that I would raise for deploying it would be that OpenStack is backed by a large community of users and companies. There are a large number of service providers deploying OpenStack, which allows you to cloud burst on demand to leverage public OpenStack clouds using the same automation you’ve already built around the OpenStack APIs.

Most importantly though, that it allows you to have flexibility to pick the best in class components from a variety of vendors rather then being forced into a vertically integrated stack.

OpenStack Summit Survey Results

As we gear up for the next OpenStack Summit in Hong Kong, and look forward to two more Summits in 2014, it’s a good time to take a look at the feedback from the April 2013 Summit in Portland.

We surveyed all Portland attendees, and almost 400 people responded. In this post I’ll break down some of the key findings and highlight a few changes we’re implementing in Hong Kong and beyond.

TL; DR Key Findings:

  • Overall: 96% of people rating the overall Summit as Good or Excellent. 
  • Top areas to improve:  Clearly the Network and the Session Rooms (size, acoustics, equipment) were unacceptable.
  • Format: Stackers favored keeping the Design Summit co-located with the rest of the Summit sessions by a margin of 4:1 over breaking it out separately



Regarding the “Session rooms” (size, acoustics, equipment), I attribute most of this to crowding issues, but there were also some technical glitches with the presentation equipment.

The Format Question:

ChartExport (1)

Among Active Technical Contributors (ATCs), who make up the majority of Design Summit attendees, the results were similar, but with more interest in making some change to the format. That said, keeping the overall event together was still preferred 2.5:1 over breaking it out completely:

ChartExport (2)


While the current format is the clear “winner” in the survey, there is always room for improvement.  Over the past 6 summits, we’ve had the most success when making incremental changes rather than completely overhauling the format.  Given the results of the survey, including the 96% rating of “Good or Excellent” I think this approach continues to make the most sense.

There were two free form questions, so I picked a few choice quotes:

“What did you find most valuable about the Summit?”

  • “The ability to get a large amount of information on OpenStack projects, progress, ideas, walkthroughs, and case studies, in a relatively short amount of time. Much better than web-based because it gets folks out of the office and thinking more constructively and creatively about OpenStack, and more passionate about it. This was my first summit, and attending it truly invigorated and greatly amplified my interest and enthusiasm in OpenStack in general.
  • “People, from all different backgrounds – both “world”-wise and Openstack-wise.”
  • “It was my first, so I was just racing from one talk to the next trying to soak up as much knowledge and personal connections as I could.”
  • “Workshops I attended & being able to speak with others who are right in the mix of OpenStack…”
  • “Hands-on labs and real world implementation strategies in the operations summit.”
  • “The fact that customers are now starting to show up at this summit is exciting.”
  • “To be able to finally meet people who I met on IRC and participate in design sessions. To be able to talk to customers.”

“What is the biggest area of improvement you see for the next Summit?”

  • “I think some logistics could improve; better wi-fi or even wired touchdown spots would be nice, since many of us need to keep working even as we’re enjoying the conference, and better sizing of the rooms to the presentations. Also the bag check idea I think would be excellent since the conference was not co-located with hotel. But overall a very well-run conference with lots of great content!”
  • “Removing barrier for non-native English speaker. They can do tremendous jobs in spite of their poor English.”
  • “Make sure participants can continue to ‘mingle’ while the number of attendees continues to grow…”
  • “1. Provide breakfast again :) 2. One evening event that accommodates all summit attendees 3. Better communication around the design sessions so they are not packed with non-ATCs.”
  • “- IRC nicks on badges – Better wifi, maybe have an on-site etherpad server since chunks of session time was lost to etherpad connection issues – Cold drinks available on site all day – don’t mind paying but never have time to go far – Conference being away from the hotel meant jetlag hurt more since going for a short nap was difficult”
  • “More seating!”

Planned actions for Hong Kong:

  • Network: We participated in a debrief with the networking company and are planning to evaluate additional vendors for Hong Kong, as well as engage with other organizations who have hosted conferences at Asia World Expo to learn more about their experience and any unique requirements we should be prepared for.
  • ATC Designation: We’re planning to make the ATC designation more clear and recognizable on the badges and include IRC nicknames. We’re also communicating that ATCs should register for the Summit with the email tied to their Gerrit ID in order to receive ATC designation on the badge.
  • Capacity & Crowding: In Hong Kong we are limiting “Full Access” passes – people who can attend the breakout sessions and Design Summit all four days — to a reasonable capacity based on room sizes, and offering a “General Session & Expo” pass with one track running Tuesday & Wednesday to better manage our growing base of attendees. Also, the “curtained off” area for the Design Summit received positive feedback in Portland and is a model we’ll pursue again for Hong Kong.
  • Design Summit Productivity & Scheduling: It has been proposed to move the PTL “project update” sessions to a series of webinars post-Summit, so they won’t conflict with Design Summit sessions, PTLs will have a chance to gather thoughts/feedback from the Summit and more people will have the opportunity to participate and ask questions online. ATCs were fairly split on having an additional moderator participate in the Design Summit sessions to help manage the room, slightly favoring bringing on the moderator.  Both of the topics are still under discussion. Regardless, we can take steps to more clearly identify “Design Summit” sessions within the online schedule and help educate Design Summit session leaders and attendees with best practices for a productive session.
  • Food & Drinks:  We will not be able to provide breakfast at the event in Hong Kong, but many of the hotel room blocks and budget-friendly recommendations offer free breakfasts. We are requesting healthier snacks for the developer’s lounge, per feedback from several developers, and we’re also planning to offer larger, reusable water bottles instead of the small plastic cups.

For 2014 Summits, we would like to continue evaluating the format, and considering the possibility of starting the Design Summit a day early (or ending a day later) relative to the other content, to reduce the scheduling conflicts for ATCs.   The data doesn’t scream out for this change, but I don’t want to dismiss it yet either for 2014.

Please keep the feedback coming! And start making plans for Hong Kong now!



Back to top