For the past few months, I’ve been mentoring a student from Tunisia, Seifeddine Jemli (“Seif”), who was working on a project I developed for him for Google Summer of Code (GSoC).

GSoC is a program Google sponsors whereby Google pays students to design, write and test code for approved open-source projects (like CloudStack) under the mentorship of one of that project’s approved contributors.

I have been developing a second SolidFire plug-in for CloudStack. This plug-in automates the entire process of creating a SolidFire volume, a XenServer storage repository or ESX datastore, and a CloudStack primary storage that can be used to house many CloudStack volumes at the same time. It works hand-in-hand with an existing SolidFire plug-in that enables each CloudStack volume to map to a single SolidFire volume (to guarantee IOPS on a CloudStack volume-by-volume basis). In short: Admins can now easily create offerings that leverage shared or dedicated IOPS.

Getting help from Seif allowed me to attack some usability issues I felt could use improvement in the CloudStack GUI, but for which we did not have the bandwidth to address in the 4.5 release (as of July 26, 2014, CloudStack 4.4 is GA).

Seifeddine Jemli, a student from Tunisia, worked on a project this summer with a mentor from SolidFire as part of Google Summer of Code (GSoC). Seif’s GUI enhancements to a CloudStack plug-in have already been demoed to SolidFire customers who have expressed appreciation for making a once tedious task a trivial one.

Seif’s first GSoC task was to improve usability with regards to adding primary storage to CloudStack that is based on a custom plug-in (like SolidFire’s). Prior to his improvements, admins needed to perform this task either via CloudStack’s CLI, its API, or some other tool that leveraged one of those. For admins who prefer a GUI when performing one-off tasks such as this, being able to configure these settings graphically is a big improvement. I’ve already been able to demo these GUI enhancements to several SolidFire customers and have received positive feedback. They all appreciated how trivial this once tedious task has now become.

Once Seif completed his initial GUI changes, I had him turn his attention toward storage tagging. CloudStack storage tagging is how admins describe their primary storages and then leverage them through compute and disk offerings in a vendor-neutral fashion.

For example, you could have one primary storage whose storage tags are “Fast” and “SSD”. You could have another whose storage tags are “Fast” and “SAS”. If your compute offering has a storage tag of “Fast”, then it can be satisfied by either of these primary storages. However, if it has a storage tag of “SSD”, then it can only be satisfied by the first of these two primary storages. (There are other considerations CloudStack takes into account, but at a high level, this conveys the right concept.)

I asked Seif to focus on the way in which these storage tags were added and edited in the GUI. The main problem to address was that the GUI expected admins to provide a comma-separated list of storage tags and did not provide insight into what storage tags were currently in use in the cloud environment.

For example, a primary storage’s storage tags might look as such:

  • Fast, SSD

Then, in a compute or disk offering, that offering’s storage tags would need to be formatted in a similar fashion to make use of the applicable primary storage.

Each line here is an example of what an offering’s storage tags might look like (all lines would match our first primary storage from above, whereas only the third line would match our second primary storage from above):

  • Fast, SSD
  • SSD, Fast
  • Fast
  • SSD

There are several problems inherent to this approach:

  1. The admin needs to make sure the correct delimiter is used.
  2. There is no obvious indication as to whether storage tags are case sensitive.
  3. There is no obvious indication as to whether there can be space characters between storage tags.
  4. The admin has to remember applicable storage tags and make sure he types all storage tags in correctly.

The approach we took to address these issues was to leverage a new GUI control in CloudStack. This control is pre-populated with all storage tags that are in use in the cloud environment (Seif had to add a new CloudStack API call to enable this). When an admin begins to type in the text portion of the control, the control will show possible matches in a dropdown. The admin can either select a match or continue typing to create a new storage tag. To enter in another storage tag, the admin simply types in a space (the control interprets a comma the same as a space).

Here is what this new control looks like in action:

Screen Shot 2014-08-20 at 1.01.07 PM.png


Once Seif had the new control and API in place and working with storage tags, he applied the same concepts to improve upon CloudStack’s host tagging (host tagging is similar to storage tagging and had related usability issues).

In the end, GSoC 2014 was a great learning experience for Seif and led to usability improvements from which the entire CloudStack community can benefit.

If you plan to be at the CloudStack Collaboration Conference in Budapest this November, come find me at the SolidFire booth and let’s talk tags (and other cool things)! Until then, I challenge you to demand more from the storage behind your CloudStack infrastructure.


Mike Tutkowski

Mike Tutkowski is a Senior CloudStack Developer at SolidFire. Mike develops software for the Apache Software Foundation's CloudStack project. He is an expert in CloudStack storage, member of the Project Management Committee for the Apache CloudStack project, and plays a critical role in developing and expanding SolidFire’s integration with CloudStack.