Category Archives: Cloud

The Rocket Ship to Havana – OpenStack Summit Spring 2013

Posted on by
1

I started this blog post as “The Road to Havana”, but immediately it struck me that the term “road” just doesn’t do this summit justice.

Day 1 was full of Heat for me. As a recent addition to the Heat core reviewer team, it was quite helpful and a pleasure to meet most of the other developers in person. This happened about 10 minutes before our first session together. It never ceases to impress me how easy it is to meet somebody in real life whom you’ve been corresponding with over only IRC and email. In this case, I felt face to face contact just added warmth and depth to already warm and friendly professional relationships.

Heat is on a path toward being a really great solution for managing large application deployments in OpenStack clouds. Continue reading →

What can Cloud do for you?

Posted on by
Reply

For a while now, many in the computing industry, myself included, have been referring to the cloud as “utility computing”. Why, Amazon is just the GE of the age of utility computing, right? HP Cloud is just building power plants to compete in that marketplace. Plug in your code, and out comes computed things.. just like the light socket in your bedroom or the one out in the shop where you make custom cedar furniture in your spare time, right?

But let me ask you this, how much power do you put back into the grid on a regular basis? How many gallons of water have you fed back into the water supply? Continue reading →

Juju and Nagios, sittin’ in a tree.. (Part 1)

Posted on by
9

Monitoring. Could it get any more nerdy than monitoring? Well I think we can make monitoring cool again…

 

If you’re using Juju, Nagios is about to get a lot easier to leverage into your environment. Anyone who has ever tried to automate their Nagios configuration, knows that it can be daunting. Nagios is so flexible and has so many options, its hard to get right when doing it by hand. Automating it requires even more thought. Part of this is because monitoring itself is a bit hard to genercise. There are lots of types of monitors. Nagios really focuses on two of these:

  • Service monitoring – Make a script that pretends to be a user and see if your synthetic monitor sees what you expect.
  • Resource monitoring – Look at the counters and metrics afforded a user of a normal system.

The trick is, the service monitoring wants to interrogate the real services from outside of the machine, while the resource monitoring wants to see things only visible with privileged access. Continue reading →

Configurate your juju’s

Posted on by
2

I was reading Jorge’s Stomp Box earlier today, and somebody mentioned how it would be an even better trick if it were easier to configure juju quickly.

Ask and ye shall receive. I hacked a new sub-command into the experimental ‘juju-jitsu’ wrapper. I’ll let the scrape from my terminal do the talking. You can get it with:


bzr branch lp:juju-jitsu

And try it with


juju-jitsu/wrap-juju
juju setup-environment

Continue reading →

But will it scale? – Taking Limesurvey horizontal with juju…

Posted on by
Reply

One of the really cool things about using the cloud, and especially juju, is that it instantly enables things that often times take a lot of thought to even try out in traditional environments. While I was developing some little PHP apps “back in the day”, I knew eventually they’d need to go to more than one server, but testing them for that meant, well, finding and configuring multiple servers. Even with VMs, I had to go allocate one and configure it. Oops, I’m out of time, throw it on one server, pray, move to next task.

This left a very serious question in my mind.. “When the time comes, will my app actually scale?”
Continue reading →

Juju ODS Demo – The Home Version

Posted on by
1

A few weeks ago I gave a live demo during Canonical CEO Jane Silber’s keynote at the Essex OpenStack Conference, which was held in Boston October 4-7 (See my previous post for details of the conference and summit). The demo was meant to showcase our new favorite cloud technology at Canonical, juju. In order to do this, we deployed hadoop on top of our private OpenStack cloud (also deployed earlier in the week via juju and Ubuntu Orchestra) and fed it a “real” workload (a big giant chunk of data to sort) in less than 5 minutes.

I’ve had a few requests to explain how it works, so, here is a step by step on how to repeat said demo.

First, you need to setup juju to be able to talk to your cloud. The simplest way to do this is to sign up for an AWS account on Amazon, and get EC2 credentials (a secret key and a key ID is needed).

If you install juju in Ubuntu 11.10, or from the daily build PPA in any other release, you’ll get a skeleton environments.yaml just by running ‘juju’.

Once this is done, edit ~/.juju/environments.yaml to add your access-key: and secret-key:. Optionally, you can set them in AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the environment.

Now, you need the “magic” bit that turns juju status changes into commands for the “gource” source code visualization tool. Its available here:

http://bazaar.launchpad.net/~clint-fewbar/juju/gource-output/view/head:/misc/status2gource.py

(wgettable here)

http://bazaar.launchpad.net/~clint-fewbar/juju/gource-output/download/head:/status2gource.py-20110908235607-pfnddi4d114nl8qd-1/status2gource.py

You’ll also need to install the ‘gource’ visualization tool. I only tried this on Ubuntu 11.10, but it is available on other releases as well.

Make sure your desired target environment is either the only one in .juju/environments.yaml, or set to be the default with ‘default: xxxx’ at the root of the file. You need ‘juju status’ to return something meaningful (after bootstrap) for status2gource.py to work.

Now, in its own terminal, run this, note that cof_orange_hex.png is part of the official Ubuntu logo packs, but I forget where I got that. You may omit that commandline argument if you like, and a generic “person” image will be used.

python -u status2gource.py | gource --highlight-dirs \
--file-idle-time 1000000 \
--log-format custom \
--default-user-image cof_orange_hex.png \
--user-friction 0.5 \
-

This will not show anything until juju bootstrap is done and ‘juju status’ shows the machine 0 running. If you already have services deployed, it should build the tree rapidly.

So next if you haven’t done it already

juju bootstrap

Once your instance starts up, you should see a gource window pop up and the first two bits, the bootstrap node and the machine 0 node, will be added.

Continue reading →

OpenStack – an amoeba on a mission

Posted on by
4

According to NASA, 70% of the earth is covered by clouds. Apparently, at least 70% of our computing needs can be covered by clouds as well. That seems to be the shared belief by the rather large crowd that gathered in Boston last week for the Essex edition of the OpenStack Design Summit and subsequent OpenStack Conference.

The amount of energy and corporate investment in OpenStack is staggering when one considers that it didn’t exist 2 years ago, and didn’t really do much more than spawn VM’s and store objects until this month with the Diablo release, which added some more capabilities, but from my point of view, mostly just refined those abilities and set the stage for the future.
Continue reading →

CloudCamp San Diego – Wake up and smell the Enterprise

Posted on by
Reply

I took a little trip down to San Diego yesterday to see what these CloudCamp events are all about. There are so many, and they’re all over, I figure its a good chance to take a look at what might be the “Common man’s” view of the cloud. I spend so much time talking to people at a really deep level about what the cloud is, why we like it, why we hate it, etc. This “un-conference” was more about bringing a lot of that information, distilled for business owners and professionals who need to learn more about “this cloud thing”.
Continue reading →

Time for some ghetto monitoring

Posted on by
5

If you came here between April 28 and about an hour ago, you got a “couldn’t connect to database” error. Oops! Seems my limited memory EC2 instance got a little overwhelmed by php processes and decided the db server, drizzled, should die to make more room for PHP. Ooops! Time to drop pm.max_children.

I don’t have any monitoring setup for the site, so I just now figured it out. Until I get proper monitoring, I’ve installed this fancy bit of duct-tape upstart magic:

start on stopping
task
script
env | mail -s "$JOB is stopping!" me@myemail.com
end script

What does this do? Well is emails me whenever upstart gives up respawning something, or I manually stop a service.

Its not monitoring. I need monitoring. But this is a nice little hack to prevent a regression while I figure that out.