Understanding Non-core Projects within OpenStack

October 14, 2015 § Leave a comment

OpenStack projects are an important part of the greater OpenStack vision. Projects can be thought of as subcomponents covering various parts of the cloud environment and are known more commonly by names such as nova for compute, neutron for networking, or cinder for block storage. The focus is more about tying together resources from a software level, while vendors such as IBM focus on enabling their infrastructure to be OpenStack compliant. As this is open source, projects follow a self-organized model where a designated Project Team Lead (PTL) seeks to carry out a vision of the project in the sense that complete functionality is delivered. Before I had a chance to take part in an IBM OpenStack Dojo a few weeks back, I had always assumed these projects were tightly coupled meaning that an ideal OpenStack implementation couldn’t have one component without another, but I’m beginning to realize this was incorrect.

First, it is clear that certain projects within OpenStack are more evolved than others. As an example, OpenStack horizon is the project to create a GUI based dashboard for controlling the rest of the environment. In my mind, a successful dashboard would incorporate monitoring but this was quickly forked from horizon into a new project known as monasca (not uncommon as projects like cinder and neutron were spun off from nova). Since the project is still emerging, the finalized vision of monasca remains to be seen, but for enterprises needing this critical monitoring functionality, the next step becomes unknown. Also, due to the loosely organized development model, it often seemed as if different projects are overlapping in functionality with no established method of determining which project to use. Because of these factors, it becomes evident that not all projects were ready for production usage in an enterprise environment.

OpenStack Simple Architecture with Compute (Nova), Networking (Neutron), and Storage (Cinder/Swift).
The simple view of three core OpenStack projects (from L to R: Nova, Neutron, Cinder/Swift) which is how I first learned about OpenStack, a cloud operating system to manage compute, networking, and storage.

While projects such as nova, keystone, glance, and swift have done a great job covering the basic mission of managing cloud elements, maybe more of the value-added elements such as monitoring, metering, and orchestration are better left as projects outside of the core emphasis of OpenStack? While this is a recognized problem, the recent “Big Tent” project restructuring effort may make this worse as now all projects, even those which are emerging, are considered official projects as long as they meet basic requirements of interoperability and meet the general OpenStack mission (before only projects considered integrated into a release were official projects). While there will be a greater emphasis on tagging to differentiate projects (for example, a stable project such as swift may be considered a part of the “stable” projects while something like monasca is tagged as “emerging”). I understand that deciding which projects to include is a choice, so an alternative view could be summarized as “if it’s too confusing, just stick to the core elements,” but I still think there will be confusion for end users creating their own environment and facing all these decisions.

For the most part this is addressed when enterprises use a bundled OpenStack distribution (which uses the most stable components and is pre-integrated), but for those companies deciding to work through the implementation themselves, how are these functionality issues addressed? The most logical answer would be the continued use of proprietary technology selectively used to “plug the gaps” (i.e. nova compute elements being used together with third party tools for monitoring). However the long term answer will require rethinking how projects emerge within the OpenStack community.

Ultimately, OpenStack is still a young project overall so growing pains are to be expected and I am sure that these challenges will be addressed. As I mentioned earlier, many projects are quite stable and do a great job managing core elements, it is just the advanced, value add type projects which may pose a challenge. In the interim though, a successful OpenStack implementation stack doesn’t have to completely coupled together; rather it will require a mix of technologies. The nature of the projects means that certain capabilities may always be weaker than others so enterprises will need to focus on incorporating the elements which make most sense to them. The key will be committing to an environment which can change over time as projects become robust enough to be implemented (if the enterprise desires).

Tagged: , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Understanding Non-core Projects within OpenStack at Thoughts and Insights from IBM Cloud Advisors.

meta

%d bloggers like this: