As many who are involved with OpenStack in some way, shape, or form know, the cadence for releases has been two a year since 2012. With the OpenStack Summit in Vancouver approaching in May, the Kilo release is imminent.
OpenStack Kilo, is hitting some big milestones today before it is released on April 30th, a series of freezes, as well as the third development milestone. Let’s take a look at the Kilo Release Schedule, and what this all means.
(Taken from the Kilo Release Schedule on the OpenStack site)
The combination of FeatureFreeze, String Freeze, and DepFreeze is a sort of lock down, so efforts can be focused on quality assurance and bug fixes before the release. Let’s take a closer look at what these freezes mean:
- Feature Freeze: That’s all, folks! We are locked into the features that will be a part of the Kilo release. Now, the focus of the the OpenStack developers will change to bug fixes and quality assurance.
- Dep Freeze: Tied to feature freeze, this freeze makes sure that our requirements and dependencies are locked and loaded. At this point, all of the dependencies Kilo has within it should be complete, so it gives time for those who want to make sure their packaged version of an OpenStack release is ready to go when the release becomes available.
- String Freeze: No new strings are going to be added to the release at this time. This is to make sure that the documentation contributors have time to do what they do best, get your documentation ready so you can begin implementation of the Kilo release as soon as it is available!
Before this triple freeze, there was the Feature Proposal Freeze. This isn’t implemented by all of the projects, but is helpful to make sure all of the earlier proposed features make it into the project with ample time for bug fixes and testing. One of the strengths of the community sources OpenStack development methodology is the ability for developers to constantly delivering improvements to features, as well as adding new ones. The Feature Proposal Freeze, gives ample time for those new features to become a reality, and be refined before the release.
Before the freeze points came, you will see there were a number of development milestones (kilo-1, kilo-2, and kilo-3) that were met. The milestones are all during the implementation stage, when code is actively being developed, and new features added. Developing new features and functionality is a lot of work, and a huge undertaking for any developer. As a developer, I can set a target for getting my code ready to review for a certain milestone within the release, ensuring my code is ready for public review before the milestone date.
If you think about it, the milestone points, as well as the freezes make a great deal of sense, especially for such a community driven development framework as OpenStack. When people hear about open source projects, many think it is a type of free for all. While it is to some degree, in the sense that anyone can contribute, there is a method to the madness. Just as you would develop your own project in your business environment, there are milestones and freezes to make sure thinks keep progressing along the way.
So what are we getting out of the Kilo release, anyway? Well, we’re getting a brand new program, called OpenStack Ironic. I’ve talked about OpenStack Ironic before, but the irony is Ironic’s use case, deploying OpenStack instances onto bare metal hardware, skipping the hypervisor layer. While some may indeed find this ironic, and perhaps unnecessary, it makes sense, especially in light of two of the more recent projects, Sahara (Big Data) and Trove (Database). If we think of some of the big data and database workloads we’ve run into, many of them are some of the last things in an organization to be virtualized, if they are virtualized at all.
OpenStack Kilo is right around the corner, along with the OpenStack Summit in Vancouver, which will be the Liberty design summit. After the design summit, the process begins again, with more great OpenStack features and functionality to look forward to.