The OpenStack Design Summit & Conference, which brought together developers, customers and more to hash out the next OpenStack release, Folsom, was a whirlwind, and in a pair of blog posts I’ll try to break down exactly what happened when OpenStack stormed San Francisco in mid-April.
I expected some good things to come out of the OpenStack Folsom Design Summit & Conference, but what I got was a TON of good things instead. There was clearly a different feel to this conference: the quality of the discussions was heightened; discussion of operations and community were highlighted; and security and high-availability had a laser focus. The past Summits have been focused on what OpenStack should look like and how to make it real, which was exactly what it needed at the time. This Summit was about putting all that effort into production and turning on the OpenStack engine for the world to see. All of this was augmented by more than 1,000 participants from 26 countries; 159 sessions during the Summit and 56 sessions during the conference; and more than 40 hours of intense discussions. This of course didn’t go without some quality relaxing and networking in the evenings — work hard play hard, the OpenStack community abides.
From the community perspective, Stefano Maffulli and Anne Gentle are truly OpenStack rock stars. Getting a community that has grown so rapidly to converge and work towards common goals while working towards the elimination of work duplication is no small task! In an effort to keep up the pace, there was a “Documentation Track” and also an “Ecosystem Track” at this year’s conference. A couple of community sessions that I attended included the “Folsom Doc’s Planning,” “Community Communication,” and “API Extensions.” Here are some highlights:
• Folsom Documentation Planning
• At the Essex Design Summit, API documentation got the spotlight and over the past six months there has been the addition of api.openstack.org and countless docs which help developers write OSAPI targeting applications. This session discussed the needs for the next OpenStack release, Folsom, and how to contribute to the different documentation projects.
• Community Communication
• There were a lot of talks about how to bring all the OpenStack contributors of the world together to continue and improve the process of making OpenStack great. Mailing lists, IRC (Internet Relay Chat), Forums and other communications mediums were discussed as ways to improve and how to maximize reach.
• API Extensions
• API extensions are a standard way to extend the functionality of APIs and expose them to users. This discussion was about creating and supporting an extension mechanism that would be simpler and easier to use.
You might have heard about both the “OpenStack Design Summit” and “OpenStack Conference.” These are in fact two different events that are placed back to back to increase attendance and cater to all OpenStack audiences. The Design Summit is typically the first three days of the week, Monday through Wednesday, and is more focused on design, architecture, code and the intricacies of OpenStack from a technical level. The Conference typically follows on Thursday and Friday and is more focused on the business and customer stories and use cases of OpenStack.
The Design Summit to me had a very production ready feel to it. Many of the talks were based on how to deploy, optimize and secure OpenStack. With 159 sessions total during the Summit, it’s really hard to pick just a few, so I’ll group topic areas together which should give an overall feel:
• Nova Security In Folsom
• This session discussed security architectural improvements that could be pushed during the Folsom timeframe. This includes discussion of encrypted internal communication and further improvements to make the rootwrap less permissive.
• Role Based Access Control
• Starting with an overview of what is now available with the Policy mechanism; this topic discussed initial and early API access to allow application of Policy against existing services.
• Trust Delegation & Cloud Federation
• This crosses on a number of topics; the intent is to allow for multiple instances of Keystone and/or multiple instances of service endpoints, sharing and/or delegating trust to relevant systems.
• Quantum OpenStack Networking Track
• Instead of focusing on just one session, I wanted to highlight the entire Quantum track. Networking across OpenStack is very important and all of the work going into it is key to its ultimate adoption by the masses. From internal only clouds to clouds that are federated across geographical locations, Quantum is being looked upon as the potential answer.
• Folsom Gets DevOps Team
• DevOps is a hot topic in the IT world today, and it’s also an important aspect to the future success of OpenStack. OpenStack needs developers and OpenStack needs Operations to meet its lofty expectations. This session begins to lay the foundation for bringing the two camps together.
• Operations Pain Points
• Operations are becoming more important as OpenStack is growing. As adoption continues to ramp up, getting a clear view of how to operate and administer OpenStack is on the minds of many individuals and companies. This session discussed problems the community sees and how to fix them.
• Folsom HA
• A brainstorm session for discussing ideas to achieve true high-availability for OpenStack components. There are many pieces of OpenStack, some pieces have been solved and others have yet to be addressed. This session lays out the plan to make all appropriate pieces HA.
• Compute Cells
• In past Summits this was called, “Zones.” Compute cells are thought to be used for geographic distribution of load but can also be used for hypervisor specific workloads, e.g., a task that favors KVM versus Xen or vice versa.
• Federated Zones With Service Catalogs
• Create a unified concept of zones across all of the projects so that deployments, operators and clients can use them to describe arbitrary geographic delineations and provide cross-project affinity between resources.
These are just some of the highlights from the Folsom Summit, and I’d like to wrap this part up from a quote from OpenStack Release Manager Thierry Carrez’s blog: “With OpenStack growing, developers can no longer follow every session and give their opinion on every subject: they have to pick their fights, and trust the other developers to come up with the right design in sessions they can’t attend. So sessions had a lot less advice-giving people and a lot more people actually signing up to do work. The topics were much more deployers-oriented and much less about changing to the latest shiny stuff. Even less glamorous sessions like bug triaging, documentation, internationalization or stable branch maintenance saw a lot a participants present, and signing up to help.”
This is nothing but good news for OpenStack, and I’m personally excited to see what the Folsom release brings in terms of the aforementioned focus points!
Be sure to check back tomorrow to see part two of Wayne Walls’ recap of the OpenStack Design Summit & Conference.