The goal of Lattice is to get a portion of the larger Cloud Foundry platform repackaged into an easily consumable system that makes getting started with the Cloud Foundry technologies straight forward for individuals and small teams. If you want to understand this a little better, watch James Bayer and Colin Humphreys talk about Lattice at the 2015 CF Summit North America.

In previous releases, Lattice was limited to only running completed Docker images within the cluster. Now that we have Buildpack support, Lattice is really able to give you a much better taste of what it means to use Cloud Foundry. Have some code? Just push it to Lattice and let it do the work to build the container for you.

Here's how to use it:

Setup

For this walkthrough, I'll be using the Vagrant box version of Lattice (using VirtualBox). These instructions assume v0.3.0 of both Lattice and the ltc command line tool. The same process should work for future versions of Lattice, we well as different deployment options (like one of the Terraform configurations for different IaaS environments).

You can grab the ltc cli tool from the bottom of the release notes.

To get the latest 

>  git clone https://github.com/cloudfoundry-incubator/lattice.git
> cd lattice
> git checkout v0.3.0
> vagrant up --provider virtualbox

This should result in a running box with the Lattice system initialized. If it worked correctly, you'll see:

==> default: Lattice is now installed and running.
==> default: You may target it using: ltc target 192.168.11.11.xip.io

By default, the Lattice box environment will be unauthenticated so it's easy to get ltc to target the cluster:

> ltc target 192.168.11.11.xip.io
Blob store is targeted.
Api Location Set

I've run into issues where xip.io doesn't resolve via some DNS servers, so if you have that issue consider using another DNS server like Google's 8.8.8.8 address.

At this point, you should have a functional Lattice system and ltc should be able to talk to it. Give it a test by running 'ltc list'.

> ltc list
------------------------------= Apps =-------------------------------
No apps to display.

------------------------------= Tasks =------------------------------
No tasks to display.

Get a Sample App

Now we're ready to find some source code that we want to run within Lattice. Since Lattice is specifically designed to be a BYOS (bring your own services), my example will not require any database or other backend services. It's a simple Python Flask based web app. Obviously it's a trivial Hello World example, but you can easily extrapolate and see how this would be useful for non-trivial systems.

The sample application we'll be using can be found on GitHub at https://github.com/chipchilders/sample-python. Go ahead and clone the repo now (from a working directory that's not within the lattice project's directory):

> cd ~
> git clone https://github.com/chipchilders/sample-python.git
> cd sample-python

There are only three files in the repo:

• Procfile - the file that helps Flask startup
• requirements.txt - the list of modules needed to run the app, in this case it's only Flask
• hello.py - the basic web app that we'll be hosting within Lattice

The contents of hello.py are pretty straight forward. The file creates a route for '/' that returns the string "Hello World! Im an instance number X", where X is the Lattice instance number (as retrieved from the app's environment variables).

from flask import Flask
import os

app = Flask(__name__)

cfindex = os.getenv("INSTANCE_INDEX")

@app.route('/')
def hello_world():
    return 'Hello World! I am instance number ' + str(cfindex)

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

My example assumes that 8080 is a reasonable listening port, since that's the default port that Lattice expects from containers. There's lots of flexibility here, but defaults will do for the example.

Build the Droplet

Lattice uses the same terminology as Cloud Foundry for the container images created via buildpacks: Droplets. Droplets are the result of taking code from the user and running it through the staging process.

Step one is to do a build of the droplet:

> ltc build-droplet sample-python https://github.com/cloudfoundry/python-buildpack

The command tells ltc to build the local directory into a droplet, naming it "sample-python" and using the cloudfoundry/python-buildpack. When you want to do something in other languages, the same process applies. Just be sure to specify an appropriate buildpack.

If everything is working correctly, you'll see Lattice stage the code and build a Droplet image:

Submitted build of sample-python
08/12 14:52:58.93 [BUILD|0] Successfully created container
08/12 14:53:07.60 [BUILD|0] -------> Buildpack version 1.5.0
08/12 14:53:07.67 [BUILD|0] -----> Installing runtime (python-2.7.10)
08/12 14:53:15.09 [BUILD|0] -----> Installing dependencies with pip
08/12 14:53:15.44 [BUILD|0]        Collecting Flask (from -r requirements.txt (line 1))
08/12 14:53:15.60 [BUILD|0]          Downloading Flask-0.10.1.tar.gz (544kB)
08/12 14:53:15.96 [BUILD|0]        Collecting Werkzeug>=0.7 (from Flask->-r requirements.txt (line 1))
08/12 14:53:16.04 [BUILD|0]          Downloading Werkzeug-0.10.4-py2.py3-none-any.whl (293kB)
08/12 14:53:16.11 [BUILD|0]        Collecting Jinja2>=2.4 (from Flask->-r requirements.txt (line 1))
08/12 14:53:16.18 [BUILD|0]          Downloading Jinja2-2.8-py2.py3-none-any.whl (263kB)
08/12 14:53:16.25 [BUILD|0]        Collecting itsdangerous>=0.21 (from Flask->-r requirements.txt (line 1))
08/12 14:53:16.31 [BUILD|0]          Downloading itsdangerous-0.24.tar.gz (46kB)
08/12 14:53:16.46 [BUILD|0]        Collecting MarkupSafe (from Jinja2>=2.4->Flask->-r requirements.txt (line 1))
08/12 14:53:16.53 [BUILD|0]          Downloading MarkupSafe-0.23.tar.gz
08/12 14:53:16.66 [BUILD|0]        Installing collected packages: Werkzeug, MarkupSafe, Jinja2, itsdangerous, Flask
08/12 14:53:16.79 [BUILD|0]          Running setup.py install for MarkupSafe
08/12 14:53:17.50 [BUILD|0]          Running setup.py install for itsdangerous
08/12 14:53:17.66 [BUILD|0]          Running setup.py install for Flask
08/12 14:53:18.00 [BUILD|0]        Successfully installed Flask-0.10.1 Jinja2-2.8 MarkupSafe-0.23 Werkzeug-0.10.4 itsdangerous-0.24
08/12 14:53:37.28 [BUILD|0] Exit status 0
08/12 14:53:37.51 [BUILD|0] Uploaded /tmp/droplet to http://192.168.11.11.xip.io:8444/blobs/sample-python/droplet.tgz.
08/12 14:53:37.52 [BUILD|0] Exit status 0
08/12 14:53:37.55 [BUILD|0] Uploaded /tmp/result.json to http://192.168.11.11.xip.io:8444/blobs/sample-python/result.json.
08/12 14:53:37.56 [BUILD|0] Exit status 0
08/12 14:53:37.60 [BUILD|0] Deleted http://192.168.11.11.xip.io:8444/blobs/sample-python/bits.zip.
08/12 14:53:37.61 [BUILD|0] Exit status 0
Build completed

To confirm that the droplet is registered in the cluster, you can run "ltc list-droplets" (or my favorite shorthand "ltc lsd").

> ltc lsd
Droplet		Created At		Size
sample-python	08/12 18:53:37.00	29.5M

Next, we will launch one instance with the "ltc launch-droplet" comment. You'll need to specify a name for the application (yes, multiple apps can be launched from the same droplet), as well as the name of the droplet to launch from. I used my imagination and named my app "test" in the example below:

> ltc launch-droplet test sample-python
No port specified. Defaulting to 8080.
Creating App: test
.08/12 15:04:55.53 [APP|0] Successfully created container
....08/12 15:05:00.01 [APP|0]  * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)
.08/12 15:05:00.39 [HEALTH|0] healthcheck passed
08/12 15:05:00.39 [HEALTH|0] Exit status 0

test is now running.
App is reachable at:
http://test.192.168.11.11.xip.io

And there we go! You should be able to see the app working by hitting http://test.192.168.11.11.xip.io. You can also now take advantage of the other features of Lattice, like scaling up / down (ltc scale), automatic health management and log aggregation.

Let's play with Lattice

To see the app list:

> ltc list
------------------------------= Apps =-------------------------------
App Name	Instances	DiskMB		MemoryMB	Route
test		1/1		0		128		test.192.168.11.11.xip.io, test-8080.192.168.11.11.xip.io => 8080

------------------------------= Tasks =------------------------------
No tasks to display.

To see the details of the "test" app:

> ltc status test
==========================================================================================
      test
------------------------------------------------------------------------------------------
Instances	1/1
Start Timeout	0
DiskMB		0
MemoryMB	128
CPUWeight	100
Ports		8080
Routes		test.192.168.11.11.xip.io => 8080
		test-8080.192.168.11.11.xip.io => 8080
Annotation	{"droplet_source":{"host":"192.168.11.11.xip.io","port":"8444","droplet_name":"sample-python"}}
------------------------------------------------------------------------------------------
Environment

MEMORY_LIMIT="128M"
PROCESS_GUID="test"
PORT="8080"

==========================================================================================
      Instance 0  [RUNNING]
------------------------------------------------------------------------------------------
InstanceGuid	a4aac9d3-fba5-453b-71ba-ec2004a17138
Cell ID		cell-01
Ip		192.168.11.11
Port Mapping	60004:8080
Uptime		3m57s
Crash Count 	0
CPU 		0.12%
Memory 		13.5M
------------------------------------------------------------------------------------------

Scaling up or down:

> ltc scale test 5
Scaling test to 5 instances
.....................
App Scaled Successfully

Now you should notice when you hit the app's web page that the index will jump around between the 5 instances on each refresh.

Also, the "ltc list" command should now show 5 instances running, and "ltc visualize" should show that there are 5 containers running on your cell (or cells if you deployed a Lattice cluster).

> ltc list
------------------------------= Apps =-------------------------------
App Name	Instances	DiskMB		MemoryMB	Route
test		5/5		0		128		test.192.168.11.11.xip.io, test-8080.192.168.11.11.xip.io => 8080

------------------------------= Tasks =------------------------------
No tasks to display.

> ltc visualize
Distribution
cell-01: •••••

And if you want fancy visualizations of your Lattice environment, check out xray.cf from the kind folks at Pivotal. It will connect to your Lattice environment from your browser, so it even works with your local VirtualBox Lattice instance.

Now let's break something!

Lattice includes both health management (keeping it's promises) as well as great logging visibility into the cluster's operations. To test this out, we can mess with the cluster by killing processes and watch as Lattice heals around our malevolence.

To start, open two terminal windows. In one, we'll use "vagrant ssh" to cause some damage. In the other, we'll watch as Lattice responds.

Get started by running "ltc logs test" in the first terminal to start watching the logs for your test application:

> ltc logs test

08/12 15:24:32.79 [HEALTH|0] healthcheck passed
08/12 15:24:32.79 [HEALTH|0] Exit status 0
...

Now in the other terminal, use "vagrant ssh" to log into the Vagrant box so we can do some damage:

> vagrant ssh
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.16.0-30-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
vagrant@ubuntu-trusty-64:~$ ps -ef | grep iodaemon | grep -v grep | awk '{print $2}'
13469
14531
14580
14636
14665

That's the list of PIDs for the 5 instances of the Lattice app. Go ahead and kill -9 one or more of them!

vagrant@ubuntu-trusty-64:~$ sudo kill -9 13469 14531

If you go over to the terminal window showing logs, you will see that Lattice will notice the issue and quickly restart new app instances within the cluster automatically.

08/12 15:28:33.13 [HEALTH|0] healthcheck passed
08/12 15:28:33.14 [HEALTH|0] Exit status 0
08/12 15:28:38.50 [HEALTH|4] healthcheck passed
08/12 15:28:38.51 [HEALTH|4] Exit status 0
08/12 15:28:40.65 [APP|0] Creating container
08/12 15:28:40.66 [APP|4] Creating container
08/12 15:28:41.68 [APP|0] Successfully created container
08/12 15:28:42.34 [HEALTH|1] healthcheck passed
08/12 15:28:42.34 [HEALTH|1] Exit status 0
08/12 15:28:42.80 [APP|4] Successfully created container
08/12 15:28:45.47 [HEALTH|3] healthcheck passed
08/12 15:28:45.56 [HEALTH|3] Exit status 0
08/12 15:28:45.73 [HEALTH|2] healthcheck passed
08/12 15:28:45.81 [HEALTH|2] Exit status 0
08/12 15:28:48.97 [HEALTH|0] healthcheck failed
08/12 15:28:48.99 [HEALTH|0] Exit status 1
08/12 15:28:49.08 [APP|0]  * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)
08/12 15:28:49.55 [HEALTH|0] healthcheck passed
08/12 15:28:49.58 [HEALTH|0] Exit status 0
08/12 15:28:50.87 [APP|4]  * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)
08/12 15:28:51.03 [HEALTH|4] healthcheck passed
08/12 15:28:51.04 [HEALTH|4] Exit status 0

So there go... All the fun of Lattice, now with buildpacks!

Starting with the car itself, I stripped it down to just it's bare essentials, including clipping the battery connector wires off of the RC circuit board to remove that board (but reuse the 3x1.5V AA battery casing). The front steering and rear drive motors were connected to the RC board via nice little female connectors that happen to easily accept small gauge pins from the seeed ARDX experimentation kit I started this whole process using. The battery casing took a little finagling to get wire leads connected to the exposed leads, but I just pushed a long section of wire into the coils.

After snipping off a bit of plastic from the frame, I managed to get a pretty flat surface for the Arduino (with motor shield) to sit on top of.  A little electrical tape, and bam...  easy mounting is always the best for quick projects.  I was also able to use the space directly above the rear drive motor to nestle a 9V battery that feeds the Arduino.

Here are some photos of the project:

The first photo shows the whole contraption with everything but the 9V battery attached (the little guy comes to life when that's attached...  I guess I need an on-off switch).

Next is the underside where you can see that I'm reusing the 3 slot battery casing for the motor power source. Also notice that little red dial on the front, which comes in handy. It's a front wheel alignment device, which was needed after all the handling I did of the car to take it apart.

Next is a closer look at the electronic stack from the front of the car. This shows one of the female plugs from the motors, and how nicely the experimentation kit wires fit right into it.

Last is the electronics stack from the rear of the car. The four wires coming out of the green terminals on the motor shield are the wiring for the two motors. The space above the rear drive motor that I use for the 9V battery that powers the Arduino is visible as well. You can also see that, when the 9V isn't on the car, there's easy access to the Arduino's USB port for uploading programs.

The circuits for this project are (again) fairly simple, since the Arduino / Motor shield combination makes it easy to use PWM functionality from the Arduino to control current flowing to the two motors. The only other connections are the two battery power sources. I actually started by feeding power from a 9V into the motor shield, and setting the passthrough jumper on the shield to allow it to send power down to the Arduino. After playing with that a bit, I realized it was better to isolate the power source for the controller from the power for the motors.

For the initial program, I hard coded a path for the car that moves it forward while executing an s-curve, then stops, then reverses a bit, and then starts all over again.

Last, here's a short video of the car in action (and getting a reaction from my dog!).

Next up, I'll be adding an ultrasonic distance sensor to the front grill of the robot (the PING))) sensor) and two infrared reflective sensors to let me do line tracking (here).

For example, here's one where there are 2 LEDs on the breadboard, one standard blue LED and one RGB LED.

Circuit Diagram:

Arduino Sketch:

Video of it in action (don't mind the mess of wires and extra parts on the breadboard...  I was playing with lots of different circuits):

First up, Digital Nibbles, hosted by Reuven Cohen and Allyson Klein, was a two guest show with Duncan Johnston-Watt (from CloudSoft) and I splitting the time. Duncan's was up first (and he's worth the listen), but you can jump to minute 25 to hear my interview. We talked primarily about CumuLogic, but also spent some time discussing CloudStack.

Next, Aaron Delp interviewed me for episode 125 of The Cloudcast. This was my second time on this particular podcast, and it was just as fun the second time around. Aaron really gets the cloud market, so it was great to discuss some of the ins-and-outs of both Apache CloudStack's community and CumuLogic's potential with him.

Thanks to both of these podcasts for inviting me to share a bit about my move to CumuLogic. Hopefully the brief introduction I gave was enough for people to understand why I made the move, and why I'm excited about CumuLogic's future!

• The planning was largely executed by the local community in Europe (tip of the hat to the amazing team at Schuberg Philis)
• Sponsorship of the conference is coming from an extreemly diverse group of companies, including many that are sponsoring a CloudStack conference for the first time (and many stalwarts of the community)
• An amazing schedule of talks, including some fantastic keynotes from industry leaders like John Willis (@botchagalupe), Mark Hinkle (@mrhinkle) and Mark Burgess (@markburgess_osl).
• The hundreds of attendees, including users, developers and many vendors that support the users and community.  

While Apache CloudStack may not get as much press as other similar open source projects, one thing really stands out to me about this community: we have an very active user-base that gives back to the project in big ways time and time again. This isn't always the case with open source software. Frequently, developers are users of their own code in some respects, but the user community tends to just take the results of that work. While the Apache philosophy is that the projects are producing software for the public good (and consider themselves "givers" with no strings attached), it's a really strong statement about the value of the software when you see so many users step up and help drive documentation, testing and user to user support for the software. In the CloudStack community, we're constantly seeing organizations and individuals start using the software and step up with support for the community in one way or another.

I consider the CloudStack Collaboration Conferences to be the embodiment of this collaborative spirit. You won't find a huge "vendor expo hall", or even thousands of attendees.  What you will find at one of these conferences is a tight nit community (OK, well, tight nit with hundreds of individuals) coming together to share their experience with others, explore ideas for making the software better and find new ways to extend the overall CloudStack ecosystem.

I've shared my views on what should make an infrastructure orchestration project's community tick in the past, and to me the key is one thing: projects like Apache CloudStack should aim to be easy to deploy and operate. IT doesn't deploy IaaS for fun. IT deploys it to be more flexible for the application owners. And the application owners don't build and deploy apps for fun either (well OK, some do). Applications are for end users, which is something that we should never forget in all the hype that surrounds "cloud".

What I've found, is that this basic understanding of why CloudStack exists is well understood by the CloudStack community. That's why our conferences are so great to attend...  they're about collaborating, sharing, learning...  all in the service of making infrastructure get out of the way for the end users.

If you're coming to the conference, find me and say hi. I always love to meet new people (or meet virtual friends in person). If you can't join us, but want a flavor for the community, watch the #CCCEU13 hashtag on twitter. We're also planning on providing live video streams of the talks (more on that will be posted as soon as we get the final details).

See you in Amsterdam!

As I spend the time to get to know the CumuLogic platform better in my new role, I’ve realized something that I think is worth sharing:

Not only are the modular / composable services useful as a developer or system administrator to make their application deployments easy, but deploying through CumuLogic platform is actually a great way to reduce your operational risk.

Think about it this way: If you’re a developer, how many times have you put off setting up a backup job for your new MySQL DB until it’s too late? For me, this is one of those tasks that I frequently forget to deal with. If you’re a sysadmin, what level of availability do you usually setup for your new databases? Do you settle for two nodes? Do you even get around to dual nodes if the requestor doesn’t ask for it? How about software updates? Do you always get to them on schedule?

The fact is, many, many databases are deployed without all of the appropriate configuration that makes them “production ready”. Backups, replicas and software updates all become trivially easy using CumuLogic’s DBaaS product. Seriously… it’s very easy.

Want your MySQL database to be in a three node cluster? Just pick that option. Want it to be 5 nodes? Click + on the node count field twice and, boom, done. Backups? No problem either… just a few clicks away, and you’ve picked a backup window, set a retention policy, and can feel confident that you’re data is safe.

An argument could be made that you could just use Puppet or Chef recipes to deploy your MySQL DB, and manage the configuration through that. Well, consider CumuLogic DBaaS as another tool in your toolbox that makes things even easier than before. How about combining your existing Puppet or Chef code with a call to the CumuLogic API to provision the database? Easily done.

Want to learn more? Head over to cumulogic.com.

So what's the new gig?

I'll be joining CumuLogic as their VP of Product Strategy as of November 4th.

Why am I betting on CumuLogic?

Keep in mind that my opinions below are just that: my opinions, based on what I know so far.

In deciding to make this move, I've spent several months getting to know the company a bit, internalizing their position and approach to the market, and hearing about their future plans. I came to the conclusion that CumuLogic has a really strong story to tell. Their focus on offering products that compliment various IaaS projects / products with modular services is the key to that story. When I say "modular services", I'm referring to DBaaS, Elastic LB, Cache as a Service, etc... Their product basically open up the possibility for public and private cloud operators to immediately add value above the basic VM and object storage services in a reusable and flexible way.

What makes me believe that these modular services are needed? Well, AWS is the clear leader in the IaaS space. This shouldn't be in question for anyone who follows the cloud services market. For me, one of the most significant reasons for this leadership is that they offer more than just EC2 / VPC / S3. These services are being adopted by Amazon's customers, particularly those customers that want to go "all in" with their adoption of the platform. And once AWS has them using these services, discussion of moving to a provider offering only virtual machines becomes exceptionally difficult.

The huge opportunity for Cloud Service Providers (CSPs), as well as IT departments offering private clouds to their internal consumers, is to expand their offerings beyond the basic IaaS elements. This embrace and extend approach to the proven AWS model has been argued to death in the blog-o-sphere (see examples here and here), and by looking at how to make their environments not just API compatible, but semantically similar, operators will be able to attract more users to their environments. Importantly, this needs to include more than just VMs, object storage and networking configuration. It requires the added services!

So again, why do I think that CumuLogic is the right place for me? Simple: They have laid a solid foundation for enabling "anything as a service", and are already successfully delivering modular cloud service capabilities to users and operators today. This includes their Database Service (MySQL), NoSQL Service (MongoDB), Load Balancing, Elastic Cache (memcached), and Framework Service features. In the future this will continue to expand, both in underlying framework choices and the service constructs themselves. It's a great starting point!

Last word, for now...

I'm obviously going to be in learning mode for the immediate future, and I can't wait to get started digging in with CumuLogic's customers, prospects, partners and (of course) the great team waiting for me there. If you're using CumuLogic, considering their products, or are a current / prospective partner, I'm looking forward to speaking with you.

Opening Keynote - State of the Project: Apache CloudStack in 2013

Slides can be found here: http://www.slideshare.net/chipchilders/cloudstack-release-41

Lessons Learned in the CloudStack 4.1.0 Release

Slides can be found here: http://www.slideshare.net/chipchilders/cloudstack-collab-2013-keynote

Panel: CloudStack & Cloud Storage: Where are We at, and Where Do We Need To Go?

I also had the chance to sit on a panel with some heavyweights in the distributed / cloud storage industry to talk about CloudStack, cloud storage and where we are going as an industry.

I'm making use of d3.js, a fantastic library that helps make it easy to bind data to page DOMs (in this case, SVG elements). You can view the relevant code on github to see the implementation details.

In the above example, there is only one pod. Clusters (there are 8 in the example) are represented by the rows of cells, and each cell represents a host.

While it was interesting to get to know d3.js better, the more interesting challenge has been in coming up with a good model for what information would cause various colors to appear. Do I focus on one capacity variable like memory? Should I just focus on host status and resource state attributes? After considering the options, I arrived at a bit of a hybrid decision about how to best approach the problem.

First, I created a view that combines a number of relevant metrics to determine the right color for each host. The primary decision point for color is the host's "resourcestate" attribute, where resource states like "Unmanaged" or "Maintenance" would grey out the host's cell. Resource states like "Error" turn the host cell red. If the resource state is "Enabled", I move on to checking the status of the host. Similar to resource state, status values that represent transitional and down conditions are immediately reflected as either gray or red.

Getting through the resource state and status checks, a healthy and "Up" host then has it's CPU and Allocated Memory capacity metrics checked. Whichever is at a higher percentage filled is then used to indicate the capacity of the host. The colors are a green -> orange -> red linear scale, with 0% being green, 50% being orange, 100% being red, and things inbetween scaled accordingly between the two closest set points.

One other thing I decided to do was to be able to select specific capacity metrics (ignoring the "which is greater" check for the overview visualization. Ex:

I'm still prototyping here, so obviously expect more testing and changes over time, but I've added this visualization to my zone dashboard:

A current issue I have with the scheme above, is that it's hard to tell the difference between a happy host that just happens to be filling up, and a host with an error. I'll have to solve that by selecting different colors perhaps.

The other issue I have is dealing with scale (there's that challenge again).  I haven't tested this out yet, but I suspect that a dashboard version of this heatmap would actually elevate the cells from being hosts to clusters (or even pods). Dynamically deciding what level of granularity to display would probably make sense.

If I get the viewing of data to the point where I'm happy, the next phase would be to consider how a large scale operator might want to perform and / or track changes to the platform itself. That's a long ways off though.

The Screenshots

The initial screenshot below will eventually be the zone listing page, who's goals should be to easily view the capacity and status of each zone. It really needs to be multi-region aware, but it's not yet.

Drilling into an example zone, the zone properties and current capacity are the first elements visible. I'm not quite sure that the properties should be as prominant, but that's what I started with. Below these bits, are trends for the capacity (go figure, trending helps in doing capacity planning!).

I've also got a very raw view into the event stream from the management server started as well:

Technical Summary

I'll readily admit that I picked Ruby and Ruby on Rails purely because I wanted to get some hands on experience with Rails (and to get a little better at core Ruby). The prototype code is on github in my cs-operator-dashboard repo.

The project is broken up into three parts:

1. cs-operator-dash: contains the Rails UI
2. cs_eventconsumer: a gem that can run a daemon process to pull CloudStack events out of a RabbitMQ broker and push them into MongoDB
3. cs_capacityretriever: a gem that can run a daemon process to periodically pull various capacity information from a CloudStack management server via my cloudstack_ruby_client gem, again pushing that data into MongoDB

Obviously this requires a running CloudStack management server (configured with the RabbitMQ event handler). It also requires MongoDB to store the data from the 2 daemon processes.

The basic concept is that the cs-operator-dash Rails app is largely read-only, and works with data being populated into MongoDB via the two daemon processes. cs-operator-dash uses the Mongoid ORM to map the appropriate models to the collections being created by the back-end processes.

One of the main benefits to using a "collector > datastore < UI" architecture is that it allows the data to be stored as a historical record (that's how I get the trend lines).

You can dig through the code if you're interested, and feel free to poke me with pull requests and / or github issues if you want to see something else. Remember though...  it's just a prototype. ;-)