OpenStack is a platform that is constantly growing and evolving, thanks in part to the massive amount of involvement in it from the OpenSource community. There are currently OpenStack releases twice a year, which are closely followed by an OpenStack Summit. While the summit in Paris earlier this month showcased lots of enhancements which were in the Juno release, the purpose of this summit was to design the features that will be released in Kilo in April of next year. Confused? Let’s take a look at how the OpenStack Design and Development process works.
While the OpenStack summit showcases all of the great new features in the latest release, it also serves as the time for the community to come together and discuss the roadmap for the next release. The OpenStack Summit is a very important process of the design phase of future releases, which is a four week cycle. The OpenStack Summit happens on the third week of this cycle, which aligns nicely with the planning phase. While new features and additions can be proposed at any time, the main benefit of being a part of the planning phase is being able to be a part of the invaluable discussions that happen at the OpenStack Summit. Ask anyone who has attended one, and they will agree, this is where the magic happens.
OpenStack Development is constantly happening, but it isn’t the free for all that you may think it is. There are freezes throughout the process that allow developers to focus on the code as it is today, and fix any critical bugs or issues that exist in the code. The freezes are FeatureFreeze, when the last development milestone has been tagged, DepFreeze, which happens in conjunction with FeatureFreeze, and puts an end to proposed changes for the cycle, and finally StringFreeze, which is a softer freeze that puts the focus on fixing strings rather than creating new ones. The freezes are key to ensure that enough time is taken to properly kick the tires on the new release. Are you one of those people that likes to break stuff? If so, it is easy to get involved with OpenStack front this prospective. Check out all of the ways to get involved, including things beyond testing and development, such as documentation, web work, or anything else you can think of.
The release phase starts with RC1 (release candidate 1), which is available once the critical bugs have been determined to be fixed. Like most other software release plans, there could be additional release candidates based on issues found during the first phase. Once everything is determined to be good to to go, our new OpenStack release is available. When Juno was released six months after Icehouse, it contained 342 new features, and was touched by 1,419 individuals in over 133 organizations. Impressed? I know I am. If we take a look at stats from the Essex release, there were only 208 developers. OpenStack provides a great stats overview so you can take a look at how much involvement has increased.
After a release, we begin again with the design phase, to determine all of the great new features that should be in our release six months later. With Kilo on the horizon, there are some great programs being worked on, as well as enhancements to existing programs. One of the more exciting projects on the horizon is the introduction of Manilla, or file sharing services. Another interesting program in incubation is Ironic, or bear metal provisioning, which, is of course perfectly suited to its name.
The OpenStack Foundation and all of the contributors to OpenStack, whether they be individuals or on behalf of an organization have made tremendous strides with the platform in the last few years. Think back to early releases, such as Essex in 2012, which were more focused on stabilization of the platform rather than future innovations. OpenStack has made massive strides in the last two years alone, and will only continue to gain more momentum as it continues to mature.
Song of the Day – Fall Out Boy – Centuries