Head in the Clouds

Hi everyone!

I'm Mike Tutkowski. I work at an exciting data-storage company in Boulder, CO called SolidFire (http://solidfire.com).

The SolidFire storage area network (SAN) was designed from the ground up to support hard Quality of Service. On a volume-by-volume basis, administrators can decide on a minimum, maximum, and burst number of IOPS - eliminating the Noisy Neighbor effect and allowing Cloud Service Providers to confidently host all sorts of application workloads in their clouds that were previously unpractical.

I am a dedicated resource to the CloudStack project. I integrate advanced SolidFire features into CloudStack while also performing general-purpose CloudStack development activities.

We've received several inquiries from our customer base regarding how one goes about configuring storage in CloudStack. To help answer these questions, I've prepared a CloudStack Storage Configuration Guide and included it in this post.

At Apache CloudStack we recently started an initiative to organize our content into learning modules. We call this initiative CloudStack University. Everyone is invited to participate by contributing content (slides and screencasts), suggesting new learning modules that are needed and even creating exercises and assignments. School fun ! As we were discussing the initiative on the mailing list we started by looking at our existing content: slideshares, youtube videos and thought about organizing them into a CloudStack 101 course. This is still a work in progress that requires everyones participation to make it a great resource.

In the meantime I have been putting all my CloudStack content on slideshare and I wanted to provide a narrated version of these slides together with hands-on demo to show folks how to do a few things with CloudStack specifically but also related Cloud and OSS tips and tricks. Here comes the CloudStack university screencasts. I will add more of them as I go along and receive requests from the community (reach out on twitter @sebgoa and tell me what you want to see). I wanted to give you a preview of what this looks like. To create a self-paced learning module, I decided to create slide decks that people can download from slideshare and cross-post the corresponding screencasts (for most of them at least) on youtube. People can choose a particular topic, or take the entire series. The idea is that at the end of watching all the screencasts and reading the material people graduate from CloudStack University.

Certainly one can imagine how this could evolve into a full fledge training and certification program. I do plan to create a final exam once I am done with a consistent set of modules :) In this post I wanted to introduce you to some of the first modules I created. I welcome all feedback and suggestions to improve them. Reach out to me on twitter (@sebgoa) or contribute your own modules via the wiki and the mailing lists.

Since my last post on the analysis of the CloudStack community, we have graduated and became a top-level project. It's about time to give an update on what can be seen as a metric of the health of our community.

All the data presented is based on the analysis of the mailing lists, the data is publicly accessible, I have used it previously, just when we graduated March 22nd, in January and back in November when I did some social network analysis. This study was inspired by John Jiang, now working at Eucalyptus, you can read his analysis, note that he moved it to the Eucalyptus website.

Methodology: As explained in previous posts, a Contributor is considered as someone who sent an email to one of the CloudStack mailing lists. This is not to be confused with a Committer which at the ASF is meant to represent someone with write access to the code. Not all code contributors have write access. I identify Companies as the email domain used by the Contributors. This is because Contributors are none-affiliated in the ASF. Obviously it has some limitations as email domains such as gmail.com can represent different companies. All emails are loaded in a mongodb database and queries are performed to extract the plots that you will see below. We currently have seven mailing lists of varying traffic: announce, users, users-cn, dev, marketing, commits, issues. Note that all JIRA emails are now sent to the issues list. Subscription to these lists and number of messages last month is as follows:

* dev@ 609 subs / ~2600 msgs in Apr
* users@ 782 subs / ~800 msgs in Apr
* issues@ 109 subs / ~2400 msgs in Apr
* commits@ 166 subs / ~3300 msgs in Apr
* marketing@ 85 subs / ~260 msg in Apr
* users-cn@ ~300 subs / ~260 msgs in Apr

Contributors: The plots below show the number of contributors per month since we became an ASF project as well as an accumulation to date. Comparison with traffic prior to joining ASF can be seen in the previous posts. The number of monthly contributors in dev is reaching 225 , while the number of monthly contributors in users is reaching 175. Most notable is that the number of contributors in the users list seem to be closing on the number of contributors in dev. It may indicate a stabilization of the number of developers and an increase in the user base. The accumulation on both lists is now over 500. A comparison of both contributor sets gives us an estimate of 806 for the entire CloudStack community. Of course this does not include people who may only participate in the marketing or announce list, but they are much lower traffic lists. It also does not include participants in the Chinese user lists. This will be in the next post hopefully. From the subscription data listed above you can also see that we have roughly a 30% activity ratio, meaning that 1/3 of the subscribers actually send emails to the lists. Difficult to know if this is a good or bad number, one would need to compare with other ASF projects.

There’s a great meme going around about geeks and repetitive tasks. Because geeks will often get annoyed at the effort of doing something manually, they often decide to find a way to automate it – which usually involves a lot more effort than doing it the one time but “geeks win, eventually” because they save time in the long run.

But in the long run we’re all dead. Then what? Who knows how to run your script? What happens when it needs to be maintained? As Jon Udell points out, it’s really not a contest, it’s a process, and non-geeks can play too. Which is why you should also write it down if you’re going to do it more than two times.

OK, “doing it more than two times” is a huge generalization. What I mean more specifically is:

• If you’re in a team environment or doing work that will keep cropping up.
• If you’re doing a task that is non-obvious and/or has a complicated series of steps that is non-obvious to people who are not you.
• If you’re in any kind of critical path that would block shipping or operations if you aren’t there to do the magical things you do.
• If you want to reduce your project or organization’s Bus Factor (help other people become proficient).
• If you want to better understand what you do and how you can improve it.

Then you need to take a step back and document the things that you do on a regular basis, because it will help your teammates and (most likely) even you when you come back to a task that you haven’t done for a long time.

Naturally, I’m thinking of this in terms of a project like CloudStack where documentation is vitally important. The success of a distributed team depends a great deal on good documentation.

(This is the official release announcement text for the 4.0.2 release. You can also find it on the Apache CloudStack blog, but I wanted to make sure we spread the news far and wide. Congrats to the project on another successful release!) 

The Apache CloudStack project is pleased to announce the 4.0.2 release of the CloudStack Infrastructure-as-a-Service (IaaS) cloud orchestration platform. This is a minor release in the 4.0.0 branch, which contains fixes for 40 bugs.

Apache CloudStack is an integrated software platform that allows users to build a feature-rich IaaS. CloudStack includes an intuitive user interface and rich API for managing the compute, networking, accounting, and storage for private, hybrid, or public clouds. The project entered the Apache Incubator in April 2012, and graduated in March 2013.

The 4.0.2 release includes fixes for a number of issues, including two minor security vulnerabilities (CVE–2013–2756 and CVE–2013–2758), problems displaying storage statistics, a fix for the SSVM HTTP proxy, support for CentOS 6.4, and other fixes.

Downloads

The official source code releases can be downloaded from: