Are you looking for the best Software Defined Storage in the market? Look no further, Standalone Cinder is here! Let’s have an overview of the Standalone Cinder service, see some specific configurations, and find out how to make requests with no other OpenStack service is deployed.

Cinder

Until not so long ago Cinder was always mentioned in an OpenStack context, but for some time now you could hear conversations where Cinder was standing on its own and was discussed as a independent service out of the OpenStack ecosystem to function as an SDS provider for non OpenStack environments.

When looking at Cinder many people only saw it as one more OpenStack services and didn’t see all of its possibilities, but those with more foresight realized a while back of the possibilities the OpenStack block storage service had to offer to the outside world, and started working on ways to use Cinder without Nova for other OpenStack projects at first, and then on its own as an independent SDS.

There are many projects out there requiring access and control of heterogeneous storage solutions, and when engineers on these projects start considering the implications of developing a solution that supports storage devices from different vendors the most common reaction is an acute head pain just thinking about abstraction design, multiple transport protocols support, proprietary control protocols, access to hardware for testing, keeping up to date with new solutions… The list just never ends!

So to avoid reinventing the wheel the normal approach is to look in the market for an existing solution that can leveraged, and you really can’t find a better solution than Cinder with its:

REST API interface

No vendor lock-in

The myriad drivers

Broad market adoption

Rich and diverse community

Direct involvement from vendor in driver development

When trying to develop a solution that requires access to storage solutions from different vendors most people’s head will start spinning just thinking about the implications, abstraction design, multiple protocol support, access to hardware for testing, being up to date with new solutions…

Unfortunately when people start looking at Cinder for an SDS solution they are usually overwhelmed by the lack of information in this regard and the implication in all available documentation that Cinder is tightly coupled to other OpenStack projects like Nova, Glance, Keystone. So facing this situation without any prior OpenStack experience can be a daunting experience, so it is my hope that this short post will help alleviate this pain.

Overview

To keep the post brief and to the point we won’t be going over all the configuration details to get a working standalone Cinder service, since that’s already documented and it’s common to all Cinder deployments, so we’ll only be addressing the ten thousand feet view of the requirements and the interesting specifics that may require more effort to discover.

When deploying Cinder in an OpenStack environment will be comprised of the API, Volume, Scheduler, and Backup Cinder services, will interact with Horizon (dashboard), Nova (compute), Keystone (identity), Glace (image), Heat (orchestration), Ironic (Bare Metal), and Ceilometer (data collection) services, and will require a message broker, a DBMS, and a storage device.

Those are the services that one must usually considers when looking at the Cinder service, but when looking at Cinder as a standalone service we will most likely want to strip it of all unnecessary surrounding services to reduce it to the bare minimum required to serve as a pure SDS; and these are the API, Volume, and Scheduler Cinder services together with all the supporting services, namely the message broker, the DBMS, and the storage device/s that Cinder will be managing.

For the message broker that Cinder uses in the method invocation between the API, Scheduler, and Volume services, we can choose -through the Oslo Messaging library- between RabbitMQ, Qpid, and ZeroMQ. For additional information on their specific configurations please look into Oslo messaging and the configuration reference 2.

NOTE: ZeroMQ was not properly supported in earlier Cinder releases, but it is now in the upcoming Cinder Ocata release thanś to Michał Dulko’s efforts

For the storage device/s, any of the supported drivers can be used, even LVM file based using a loopback device, although this is obviously not recommended.

Cinder configuration

Basic Cinder configuration is beyond the point of this short post and should be well covered in the Cinder documentation and vendor’s drivers documentation.

From Cinder’s perspective it’s quite easy to do without most of the OpenStack services since the service is mainly acting as a provider and doesn’t call any of the services of it’s own accord. This is the case of Horizon, Nova, Heat, and Ironic services. So we can just go ahead and ignore all those as if they didn’t even exist.

NOTE: Without Nova, special feature assisted snapshots will not be available.

Ceilometer isn’t a problem either since Cinder doesn’t require it to be present as Oslo messaging’s notifier will not send anything to the message broker if the notification transport mechanism is not configured. Although nothing gets actually sent, the actual mechanism is still unnecessarily wasteful as it is now, since we go through the trouble of preparing the actual message -sometimes this entails querying the DB-, so I created a Launchpad bug and proposed a patch to short-circuit this mechanism when there’s no notification transport mechanism configured in Cinder.

Now that we know we can ignore Horizon, Nova, Heat, Ironic, and Ceilometer, that leaves us with with Keystone and Glace.

Keystone is used not only as the authentication provider but also for the service catalog, which means that if we want to remove Keystone in our deployment we’ll have to know where our cinder service is to make our requests, which doesn’t seem like a problem, and to disable Keystone authentication.

Disabling Keystone authentication is quite simple, all we need to do is to change the auth_strategy configuration option in our cinder configuration file from keystone to noauth under the [DEFAULT] section. And since we won’t be using Keystone that means that we won’t be needing any [keystone_authtoken] section in the configuration.

If disabling authentication is not an option for our use case we can always add custom Middleware to deal with our own authentication system. How the authentication mechanism works and how to add a custom authentication mechanism are out of the scope of this post, but I’ll to do a write up on it in the future.

We are almost done, now we only have to look at Glance. As the image provider service, Glance is a service frequently used by Cinder, so if we don’t deploy it in our environment that means that any request we make to Cinder that requires of this service will fail after Cinder fails to contact Keystone to get the location of Glance from the catalog, or to connect directly to Glance if we have set it up that way.

Some of the operations that require the usage of Glance and that will not be available are creating a volume from an image, and uploading a volume to an image. For the upload to image functionality we can prevent it from being accidentally used using the policy mechanism, but for the volume creation using an image as the source we currently have no mechanism to disable it, so I proposed one.

To disable creating image from a volume we have to make sure our JSON Cinder policy -usually in /etc/cinder/policy.json– for that action is set accordingly:

If we want/need to have those features available we can always deploy Glance without authorization just like we are doing with Cinder.

Using Cinder

Now that we have deployed Cinder without authentication it is time to use it. So we know that Cinder has a REST API interface, and that we have disabled authentication, so the first thing we’ll try to do is to do a sanity check of our service with a request using curl.

CURL

As a first step we go to the Cinder API documentation and look for one of the simplest REST API request and we pick the volume listing endpoint, and see that we require a tenant_id parameter for that – /v3/{tenant_id}/volumes/detail – so we decide to call the tenant admin_tenant and we make the query, but to our surprise it doesn’t work as expected:

So what happened here? Well, if you think about it you’ll see it makes sense, you have disabled authentication, but the authorization mechanism is still in place, and since Cinder is a multi-tenant service, you’ll have to specify the user and project/tenant to use on your requests, even if they are not going to be authenticated.

Not all projects handle this in the same way, but Cinder and Nova both use the X-Auth-Token header field to pass the user and project’s ids separated by a colon. Cinder will accept any arbitrary string up to 255 characters in length as user and project, they don’t need to be a valid UUID. So now that we know this we can try again:

NOTE: Please be aware that the tenant in the URL and the project in the X-Auth-Token header must match or we’ll get a 400 malformed request url error

Since we have disabled authentication Cinder will believe any user and tenant id we send and it will treat all request as made by an admin user. Having users and tenants is still useful, as we’ll be able to use all Cinder features normally, like filtering volumes by user and not getting all volumes mixed up when we list them.

Even though it’s not supported by Cinder, you can make some small modifications to the code -or create a custom middleware authenticator- if you want to always use the same user and not require the X-Auth-Token header in your REST API calls, or you can even set all users as non admin users unless the user parameter is “admin”. To do this you just need to change the NoAuthMiddleware class in cinder/api/middleware/auth.py.

For example, to always use admin user and project you’ll need to change the class to something like this:

And if we want to only make the context as admin when the user is “admin” we just have to change is_admin=True, with is_admin=user_id=='admin',.

For API version 3 one must remember that Cinder uses microversioning to support introducing breaking changes within the same major version, so we’ll also need to send header 'OpenStack-API-Version with the version we want to use, for example for version 3.10 we would do:

Cinder client

We are now up to a great start as we can already send commands, but there are so many operations and parameters available in Cinder -more so now than ever with the introduction of microversions- that it’s hard to find the ones we want, and sometimes we just want to do a quick test, or want to see a specific example of the query we need to send, or we just don’t want to do the API queries ourselves; and this is where the Cinder client can be a great help for us since it has support to almost all possible operations, can work as a CLI tool or a a python library to use in your own code, and can present the exact curl queries that have been used to make the call.

NOTE: the download URL will change as new patches are submitted to resolve merge conflicts, so the patch should be checked for the latest download link.

So with that patch in place we can now instruct the Cinder client to work with noauth by passing the --os-auth-system=noauth parameter in the command line or setting the OS_AUTH_SYSTEM=noauth environment variable.

When working with noauth the client will require at least 2 parameters, the user id and the cinder URL. The project id is optional as will default to the user id if not provided:

NOTE: Remember that your tenants will still be subject to existing quota restrictions.

Now we’ll be able to do all operations supported by the Cinder client, but there are some operations that are not supported by the client because they were only called by Nova and didn’t make sense to be be exposed to outside users. But please don’t misunderstand it, the REST API is open and can be accessed by anyone, it’s just that the client doesn’t expose those operations.

Recapitulation

Cinder as a standalone SDS service is the perfect solution to seamlessly access a wide array of heterogeneous vendor storage devices through it’s REST API support and broad range of operations.

The service can be accessed programmatically using REST API requests, or using the Cinder client as a library or as a CLI tool.

We have recently started an Etherpad to gather use cases and potential work that we would like to do to cover all user cases. If you have any specific use case, functionality, or bug, please don’t hesitate to add it to the Etherpad so it can be taken into consideration.