OpenStack Project Technical Lead Interview Series #3: John Griffith, OpenStack Cinder (Block Storage) Project
This post is the third of a continuing series of interviews with OpenStack Project Technical Leads on our Mirantis blog. Our goal is to educate the broader tech community and help people understand how they can contribute to and benefit from OpenStack. Naturally, these are the opinions of the interviewee, not of Mirantis. We’ve edited the interview for clarity and post length.
Here’s the interview is with John Griffith, OpenStack Cinder (block storage) Project Technical Lead.
Mirantis: Can you please introduce yourself? What is your history with OpenStack and why do you engage?
John Griffith: Back in 2011 right before the summit in Boston, I was hired by SolidFire specifically to come on board and contribute to the OpenStack project. It started out as many did in the storage industry: add a driver, fix a few bugs ... During the summit in San Francisco myself and a few others proposed Cinder as its own project and things have just continued to grow for me from there.
As far as the why, for me it’s really about Open Source the Cloud and *what* OpenStack represents. OpenStack to me is such a fantastic and needed game changer in the industry, I love being a part of it, that includes contributing code, evangelizing and using it.
Q: What are your responsibilities as the Cinder Project Technical Lead?
A: There’s a pretty good description of what it takes to be a PTL on the OpenStack PTL guide, but the short version really is: Act as the technical lead and ambassador for the project.
Being PTL is actually one of the harder jobs I think I’ve had. The technical portion is challenging of course, but all of the project maintenance work with release plans bug targeting, working with the community on the future direction of the project; it’s really a full time job, and I think anybody who contributes in the role of PTL has to be pretty passionate and dedicated to the project.
Q: Can you explain Cinder’s role within OpenStack? Why does Cinder matter?
A: Cinder is the OpenStack Block Storage Service in OpenStack. Block storage is the persistent higher performance storage that’s used in OpenStack to attach to instances or to use as bootable media for your instance and provide you with persistent instances.
Cinder matters because Block Storage in the cloud is a critical need, what I mean by this is in order for OpenStack to be adopted for more than test/dev workloads and to become full on true Infrastructure as a Service (particularly in enterprise/private cloud) there’s a requirement for persistent, predictable performance block storage. This enables things like running databases, big data workloads etc.
Q: What is genuinely unique & disruptive about Cinder?
A: Well, in the cloud space (and actually compared to traditional block storage as well), what really sets Cinder apart is the ability to scale and the granularity that it provides. With Cinder you have control of your storage at a volume level, you can deploy a single volume to your compute instance as opposed to an entire back-end device and carving it up for example. There’s also the point of scale and heterogeneous storage. You can have multiple back-end storage devices each with their own specific strengths and weaknesses, all of them being in your pool and all of them available depending on what your current deployment need might be. In a nut shell Cinder is embracing the concept of Software Defined Storage.
Q: What has the Cinder community accomplished so far?
A: I’m a bit biased of course, but I’m pretty proud of what we’ve accomplished in just little over a year. We’ve created and launched the project of course, but we’ve also continued to grow the project making it more reliable and adding key features. Along with features like simplified boot from volume, multiple backend config support and some pretty cool advanced scheduling, we’ve also seen a huge increase in interest from storage vendors. We’ve added close to a dozen drivers in the Grizzly release and maintained compatibility in the API’s and interfaces.
Q: Which capabilities will Cinder provide in the OpenStack Havana release?
A: There’s a pretty long list of things that we want to enhance and improve upon specifically around quality and reliability of the base service itself, but also in terms of new features. We’re working on things like bare-metal service deployments, providing the ability to share volumes among multiple tenants and the ability to attach to multiple instances at a time.
Q: Does Cinder disrupt classic enterprise storage, or is it complementary?
A: Well, I definitely think it’s disruptive, this is pretty evident by all of the storage vendors that are actively submitting drivers or trying to submit drivers for their traditional storage devices to Cinder. Software Defined Storage is for sure changing things in my opinion, I think the phase we’re in now is more of the mind shift at the enterprise data center space from traditional IT to Infrastructure as a Service. For those shops that are realizing the benefits and potential of Software as a Service it’s definitely disruptive.
Q: What are typical best practices for Cinder? And which use cases benefit most from Cinder?
A: Best practices that come to mind are plan to scale and to know your requirements. Cinder is great at abstracting out the various storage back-ends and providing block storage as a service, but it’s important to keep in mind that the different back-ends you use will have different performance characteristics. You can target specific backend types for specific workloads and keep this fairly transparent to your end user, but this means you have to think ahead and have some knowledge regarding what your end users are expecting and plan to use Cinder for.
The great thing about Block Storage as a Service is that you can actually cover multiple use cases in a single Cinder deployment by pooling the various back-end storage devices. The provides the ability to allocate based on what the end user needs, and even offer the ability to adjust based on their actual day to day usage. Along with this the use case that benefits most is the one that requires dynamic capacity; for example if you know you’re storage requirements are going to grow over time Cinder (and OpenStack in general) enable you to scale out dynamically as needed.
Q: Are there any misconceptions that people bring to block storage in the cloud and should they approach it differently compared to conventional block storage?
A: Yeah. I think so. Block storage in the cloud is still a fairly new concept. One of the big differences and advantages is software-defined storage, and actually the fact that you abstract a lot of the differences away from all the various back-ends that you might use and all the old APIs and everything else and you make that all a common pool.
One of the big things that cloud block storage gives you is actually much better granular control. So you have granularity at a single volume level, and you have that abstraction of the custom APIs, and it makes a huge difference.
So that’s different to the old paradigm where folks looked at traditional block storage as: “Hey, I’ve got a big monster disk array with RAID 10 on it and I want to use it because it has these special characteristics. So I’m going to connect it to these compute nodes in my system and that need xyz characteristics. And then I’m going to have this different system that I want to use and deploy in another part of my IT shop for these machines ...” and so forth. With cloud block storage the idea is: Everything is in that pool and you actually select it from that pool based on your needs, you matchup compute resources with block storage resources as you go.
Q: How do you suggest people should approach capacity planning for volume block storage in the OpenStack cloud?
A: So capacity planning is always a tough one because there’s so many variables that go into it, but the beauty of block storage in the cloud is the fact that it is scalable and you can continue to expand it. So of course you have to come up with your initial target requirements and things like that, but you can just go ahead and add another back-end device into your pool and continue to grow or even remove it as you need.
Q: Are there any things that you wish people knew about this project? … hidden benefits that people are not aware of?
A: As far as hidden benefits, I don’t think anything is hidden so much, but I think folks still just look at Cinder as persistent storage that you can attach to an instance and use for testing or development applications. The reality is you can move real applications and workloads, and get real performance, this includes things like e-commerce, databases etc.
Q: What are the necessary prerequisites in order to deploy Cinder?
A: From an OpenStack in general perspective, there’s quite a bit of information and requirements. You definitely need to have a pretty good conceptual idea of all the different components inside of OpenStack which can be tough.
The hardware requirements for Cinder depends upon what you’re deploying for your actual storage back-end. If you want to use the reference implementation of LVM to start with you will want to have a couple terabytes of SATA disk inside of a node with decent memory, and processor capacity.
Q: How long would it take to deploy Cinder?
A: That’s kind of a tough question. I think with all the various components you truly want to understand OpenStack, be able to troubleshoot and maintain it properly - you need to have a person dedicated to learning how to administer OpenStack. On the Cinder side you could probably spend a week and come up to speed, understand it pretty well to maintain and implement it, but as I said you definitely want to have a dedicated resource that focuses on administering OpenStack.
Q: Whom would like to see contributing to Cinder?
A: First and foremost, those that are passionate about OpenStack and open source software in general. Many of us of course have our own self interest or business reason for contributing, but those who really stand out are people who have a balance of both their own business needs and the community and project as a whole.
In terms of skill sets, there’s a couple of things. Of course you want somebody who is a great software developer and has good Python skills, since everything in OpenStack is Python. But along those lines also some who understands the concept of scale-out computing. In short, someone who has an understanding of what cloud computing is all about and what the different dynamics and paradigms are versus traditional computing.
One of the things that I see happen a lot, and that’s difficult sometimes, is people coming in and trying to put traditional computing paradigms into OpenStack as a cloud computing model which doesn’t really work. You can do that, but it’s not necessarily the direction that I think we should go.
Q: What are the top three features on top of your mind new contributors should focus on?
A: Yeah, as far as contributions for things coming down the ramp that people might want to look at are things like state machine to Cinder to keep better track of volume status and states throughout the lifecycle of the volume. We want to look at doing some things like adding LIO support and getting that ramped up and better.
There’s always room for improvement around how the quotas are implemented right now and adding new quotas. One of the things that I talked to somebody at a meet-up just recently about was a concept of having grouped quotas as opposed to just individual tenant quotas.
Q: What are the very first steps prospective contributors should make?
A: Engaging via mailing lists and IRC is a good starting point. It’s overwhelming at first, but really it’s not as bad as it first seems. IRC is the best place to communicate, openstack-dev is the general developers channel, just pop in. For Cinder specific development questions we also have an openstack-cinder channel that’s a great resource. I also recommend to start with the OpenStack How to Contribute wiki page and withh devstack.org. It gives you a chance to deploy a working OpenStack environment on a VM so you can poke around and have a good look at how things work.
Q: Thank you very much, John!
A: You’re welcome!
