There is a lot of buzz in the industry around OpenStack. The name is used alongside major players on both the public cloud, as well as in private cloud product environments. This is with good reason and we have seen a significant upswing in organizations taking an interest in finding out about how OpenStack may become a part of their environment.
Here at VMTurbo we are doing a lot of work around our integration with OpenStack, but one of the most important things to understand when we talk about OpenStack is to really try to define exactly what “it” is. This is the first of a series that we are going to produce to help everyone get up to speed on OpenStack and how it is impacting the industry. This is a part of our commitment to the OpenStack community and the IT community in general and we welcome comments on what you would like to learn about our OpenStack work.
What is OpenStack?
According to the definition at OpenStack.org:
“OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.”
OpenStack began as a partner development with NASA and Rackspace which led to the first release in 2010, codenamed Austin. Each release of OpenStack has a codename marked by the next alphabetical order and an associated word. Major releases have been launched on a semi-annual basis with the order of them being Austin, Bexar, Cactus, Diablo, Essex, Folsom, Grizzly, Havana, Icehouse, Juno, and the upcoming Kilo.
Each OpenStack release will also have additional point releases and the version number is iterative based on the year of release, the edition release of that year (1 or 2) and then the third digit which is the release number. An example is that the Icehouse edition was version 2014.1 (April 17, 2014), 2014.1.1 (June 9, 2014), 2014.1.2 (August 8, 2014), and 2014.1.3 (October 2, 2014). When the next full release comes out, the previous release no longer increments and updates come only as security patches where necessary.
Fixed Release Dates – Variable Features
One thing about OpenStack development cycles is that they are fixed on the calendar in advance of the next full release. We already know that the Kilo release will be available as version 2015.1 and will come out on April 30, 2015.
The way that the OpenStack development process works is that the features will be integrated using a well-orchestrated CI/CD (Continuous Integration/Continuous Deployment) methodology and that only tested, working features are put into the code base, referred to as the trunk repository.
This aggressive technique has been developed and maintained well, even with thousands of developers working to submit code into OpenStack. This itself is a feat that many organizations have had trouble embracing.
The programs, often also called projects, are the different portions of OpenStack that make up the operational components to run your cloud environment. Programs are divided into different categories based on how tightly they tested and integrated.
Programs are categorized as:
Over the last year, programs were often referred to as “core”, but this has been changed to integrated. Admittedly, it can be confusing if you read different documentation due to the change in terms along the way.
Incubation programs are those that are not yet considered to be fully integrated. This is based on a variety of criteria including testing processes and the maturity of the features. Incubation programs will go through what is called a graduation process, and they are considered incubation programs for 2 full development milestones.
New programs are called External programs and also have a process that they must follow to be brought forward to become an official OpenStack incubation program. There is the need to have a well-defined scope to show the features that it will add to the OpenStack ecosystem. A level of maturity on the development process is required so that a momentum is already in place to keep the program developing to help grown the OpenStack feature set.
These program levels have been well established now over the 4 years since the inception of OpenStack and are a key part of the successful development and release process. Most importantly, all of the program code must adhere to the Apache License v2, include documentation, and also provide a RESTful API and Python client library.
The OpenStack Developer Ecosystem
Each OpenStack program is led by what is called a PTL, or Program Technical Lead. The PTL is charged with the task of maintaining the codebase and features which are in the backlog as we go from release to release.
The PTL and the supporting team will work to integrate code that is submitted upstream by developers. The developer ecosystem can include individual programmers, as well as corporations who provide with their development teams. The OpenStack Foundation itself has developers who maintain and contribute code also to help drive the development.
As of the Juno release, there were 1,433 code developers including 201 core developers, 444 regular developers, and 795 casual developers. The classification is based on participation levels and the amount of time dedicated to the development on OpenStack specifically.
From the overall code submitter pool if 1,828 contributors, there were 18,992 commits overall to the Juno release. Remember that this all took place across the world and over a seemingly-compressed 6 month development cycle.
We can compare it to the Icehouse release, with 1,224 code developers, 1,358 submitters, and 17,879 commits, we can see that this is a growing number. This is an impressive number to say the least, and it reflects the upward momentum of the OpenStack ecosystem all around.
More to come!
Our next post will dive into the OpenStack Foundation itself, and then look at the integrated programs that were included in Juno release.