The great thing about working in Open Source is that often one can drive a single mission through multiple organizations to an end goal that makes the most sense for the community. I hope that some find the changes I made to OpenStack while at HP useful both inside HP, and outside. They were a fantastic employer and I’m eager to see where HP Enterprise goes from here.
That said, I’m extremely excited to be joining IBM to work on OpenStack from a different angle. We’ll be doing some really cool things, and I just can’t wait to get the ball rolling! In fact I won’t have to wait as today is my first day, and I’m here in North Carolina at the Research Triangle Park to begin my assimilation into the borg.. er.. to be oriented for employment at IBM.
Medical doctors have a fairly well understood job, at least on the surface.. I think. People arrive in front of them, and describe their problems with a specific mind to get those problems solved. A medical doctor observes, listens and examines, and then takes action based on incomplete information. They may decide to run tests, or take a best-effort guess at a treatment plan. At this point, they are prescribing to solve problems which the owner of the problem cannot solve themselves.
Engineers sometimes act like doctors. Specifically, I have often acted in this way in the past. At times, this works out well. A confused set of engineers describes their issues, and I can respond with strategies to fix them.
However, when an engineering effort reaches a certain size, this simply does not scale. As the doctor, you will either be crushed under the weight of so many requests, or you will be operating under such stress that your information will be wildly inaccurate and your understanding of each team’s problems will be skewed. Continue reading
Up until recently, I felt like Facebook/Google+/Twitter/etc. had made life better. I told myself that I could live ANYWHERE in the world and still be so close to everyone.
Oh how misguided that view is. I posit that the truth is really quite the .. op..posite. The more I lean on Facebook to keep me close to my “friends”, the further they seem from me. When I meet somebody new who seems like they’d be a good friend, exchanging facebook information just means we probably won’t ever see eachother again. Continue reading
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
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
"Vest over t-shirt pwns half-shirt, Bill!"
That is the word that I would use to describe the work done by my fellow engineers at Canonical over the past 2.5 years. However, it is time to move on.
"I think I'm gonna hurl, Bill"
Its not an easy thing to move on from what is truly the best job I’ve ever had. However, it is time. I’ll discuss more here after my last day at Canonical, which will be very soon, December 5th. Suffice to say, I won’t disappear from Ubuntu, so stay tuned!
If you’ve heard of Juju (and chances are, if you’re reading my blog, you have!), take 5 minutes and go take our Juju Community Survey
In my previous post about Nagios, I showed how the rich Nagios charm simplifies adding basic monitoring to Juju environments. But, we need more than that. Services know more about how to verify they are working than a monitoring system could ever guess. Continue reading
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
This week, William “I code more than you will ever be able to” Reade announced that Juju has a new feature called ‘Constraints’.
This is really, really cool and brings juju into a new area of capability for deploying big and little sites.
To be clear, this allows you to abstract things pretty effectively.
juju deploy mysql --constraints mem=10G
juju deploy statusnet --constraints cpu=1
This will result in your mysql service being on an extra large instance since it has 15GB of RAM. Your statusnet instances will be m1.small’s since that will have just 1 ECU.
Even cooler than this is now if you want a mysql slave in a different availability zone:
juju deploy mysql --constraints ec2-zone=a mysql-a
juju deploy mysql --constraints ec2-zone=b mysql-b
juju add-relation mysql-a:master mysql-b:slave
juju add-relation statusnet mysql-a
Now if mysql-a goes down
juju remove-relation statusnet mysql-a
juju add-relation statusnet mysql-b
Much and more is possible, but this really does make juju even more compelling as a tool for simple, easy deployment. Edit: fixed ec2-zone to be the single character, per William’s feedback.