// October 22nd, 2011 // Comments Off on Juju ODS Demo – The Home Version // Uncategorized
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:
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.
Those particular charms were specifically made for the demo, but most of the changes have been folded back in to the main “charm collection”, so you can probabl change lp:~mark-mims/+junk/charm- to lp:charm/.
You will also need a file in your current directory called ‘config.yaml’ with this content:
These numbers heavily control how the job runs with 1 or 100 hadoop instances. If you want to spend a couple of bucks in Amazon, and fire up 20 nodes, then raise job_maps to 100 and job_reduces to 100. Also job_size to 10000000. Otherwise its over very fast!
We started the demo after bootstrap was already done, so the next step is to deploy Hadoop/HDFS and ganglia to keep an eye on the nodes as they came up.
This causes the “juju expose jobmonitor” to fail, which means you may not be able to reach the ganglia instance. You can fix this by stopping/starting the provisioning agent on the bootstrap node. That is easier said than done, but can be scripted. Its fixed in juju’s trunk, so if you are using the daily build, not the distro version, you shouldn’t see that issue.
So once you’re done, you’ll probably want to get rid of all these nodes you’ve created. Juju has a tool that strips everything down that it has brought up, which can be dangerous if you have data on the nodes, so be careful!
It does not have a ‘–force’ or ‘-y’, by design. Make sure to keep the gource running when you do this. Say ‘y’, and then enjoy the show at the end.
I’d be interested to hear from anybody who is brave enough to try this how their experience is!
The image uses OpenStack Diablo, requires an x86_64 compatible desktop/laptop machine, and is approximately 560Mb in size. We recommend flashing to a 4GB USB drive (or larger) to allow for proper setup and use of the cloud. Use the ‘dd’ command to copy the image over to your USB drive. For example, if your USB drive is connected to /dev/sdb, make sure the drive isn’t mounted, and then run `dd if=ubuntu-11.10-cloud-live-amd64.img of=/dev/sdb`. WARNING: THIS COMMAND WILL ERASE ALL DATA PREVIOUSLY STORED ON THE TARGET DEVICE. MAKE SURE YOU HAVE THE CORRECT DEVICE WHEN FLASHING.
Once flashed, simply boot your laptop/desktop from the USB drive and follow the instructions displayed on the desktop.
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.
Attending as a member of the Ubuntu Server team and a Canonical employee was quite a gratifying experience. Ubuntu Server has been the platform of choice for OpenStack’s development, and that has definitely led to a lot of people running OpenStack on Ubuntu Server. Its always nice to hear that your work is part of something greater.
On the surface, one might be concerned at a lack of vision in the OpenStack project. With so many competing interests, it may appear that it has no clear vision and is just growing toward the latest source of funding or food, much like an amoeba swallowing up its next meal. But the leadership of the project seems to understand that there is still a much greater mission here, that without intense focus the project will expend enormous energy and accomplish little more than falling a little less behind established players in the marketplace.
Its a bit vindicating for one of my more intense current interests, Juju, that others who are close to this discussion, like OpenStackers, are thinking along the same lines. In talking with Puppet and Chef guys and with people who are using the cloud, its clear to me that my hunch is right; chef and puppet are not really the same thing as Juju. The new project from Cisco, Donabe, seems to be thinking exactly like Juju, wanting to encapsulate and describe each service in what they call “Network Containers”. Also I’m told the desires of the Neutronium PaaS project are pretty similar as well.
Ultimately we don’t think that the current limitations of known PaaS stacks are always worth the effort to integrate with them. We do want to have a lot of the same capabilities without having to duplicate all the effort to set them up. We want to be able to make use of well understood technologies without having to understand every detail of their deployment and configuration. If I want to make use of MySQL or memcached, I should understand how they work, but I shouldn’t have to duplicate the effort that others have had to put in to make them work.
Chef and Puppet have made some inroads into this by making such things highly repeatable and getting them all into source control. However, its my belief that their implementations both limit the network effect that they can have to build up a full set of sharable services. Juju, I think, will really be a boost to those who have spent a lot on solid config management, as that config management will be easy to chop up into Juju charms, and then that will open up all the other existing charms for immediate use in such a shop.
Getting back to how this relates to OpenStack, it was also quite exhilarating to do a live keynote demo of Juju in all of its alpha glory. To raise the tightrope a little higher, it was driving OpenStack Diablo, which some might call beta-quality. We also got rid of the safety nets entirely, and had it running on top of Ubuntu 11.10 (pre-release). We had a few kinks through the week, but the awesome team I had around me was able to iron them all out and made both our CEO, Jane Silber, and me look very good up there. That includes my fellow server team members, the OpenStack developers, Canonical IS pro’s, the Juju dev team, and my main collaborator in the whole thing, Jorge Castro.
I hope to attend the next ODS, to see how much closer OpenStack is to completing its mission in 6 months. What is that mission currently? Quite simple really.. the mission is, figure out the mission.
Today our CEO Jane Silber announced at the OpenStack Conference in Boston that HP has chosen Ubuntu as one of the initial lead host and guest operating system powering their Public Cloud. HP and Canonical are working closely together during the current private beta to make certain that we provide the most secure, scalable, business-class cloud to companies of all sizes. We are excited to join with HP in recognizing that open and interoperable cloud infrastructure and services are critical in delivering the next generation of cloud-based services to developers, ISVs and businesses. Both companies share a common commitment to open source and both embrace the OpenStack community. With over 117 member companies the momentum behind OpenStack is truly game changing and promises to position it at the center of the next wave of computing.
This is an important announcement on several fronts – that OpenStack is seen as the platform of choice for building out the largest Public Clouds, and that Ubuntu has what it takes to power OpenStack clouds as a scalable and hardened host OS and responsive and flexible guest OS.
Ubuntu is the reference OS for OpenStack but like in any other open source project we need to earn our keep on a daily basis and having HP select us is a positive reflection of Ubuntu as a Cloud OS.
Since we’re very close to the Oneiric release, I’m starting a series of articles about Ubuntu “Server Trenches”. I will be interviewing members from the Ubuntu server team, where you get to read all the juicy details of what the team has been working on. You also get the chance of asking away any questions you may have. I am starting the first article with Robbie Williamson the Ubuntu server engineering manager. He’ll give us a high level overview of Oneiric server features and things the team had worked on this past cycle, as well as future directions. In future articles we’ll zoom-in on features and meet more of the server team engineering members.
Robbie’s article should hit the wire this Thu 6th Oct, now here’s the deal, if you’d like to ask Robbie anything, leave me a comment right here with your questions. Robbie will try to answer as much of your questions as possible.
Early celebration of Oneiric? YES! the party has begun
// September 26th, 2011 // Comments Off on Juju in 11.10 beta2, LXC and OpenStack improvements // Uncategorized
A new version of juju has been merged in Ubuntu 11.10 beta-2, if you’re not already running Oneiric beta, you can download the beta-2 ISO and start experimenting. Let’s checkout the latest happenings in the juju world
The juju ppa has been updated (migrated from Ensemble). You can now install the juju ppa using sudo add-apt-repository ppa:juju/pkgs
Clint has prepared the final freeze excpetion for including juju into 11.10 beta-2. You can read more here
TONS of work are landing in juju trunk to enable “local developer” mode. This will enable a juju user to deploy charms locally (say on a laptop) using Linux Containers (LXC) as a light weight virtualization solution. Most of the work for this was merged already, expect a major announcement and post about it very soon
Clint committed further fixes and improvements to the juju test suite improving robustness
Kapil besides spear heading the local developer story, has also committed needed fixes for improving OpenStack compatibility. This means that juju can now target an openstack cloud just as it targets ec2. This is part of the effort needed to provide a seamless and integrated juju experience with “Ubuntu Cloud Infrastructure”, the new Ubuntu cloud product based on OpenStack (superseding UEC)
Juju now by default launches Oneiric AMIs on EC2. Always a sign that Oneiric is taking shape
Gustavo and the team are still working hard to bring you the charm shop (or whatever it will be called). This provides integration between juju and launchpad so you can search download and use charms right from juju and have an integrated experience. Hang on tight for this one
Charms too got their fare share of updates
LOTS of charms are being worked on to fully provision the openstack based “Ubuntu Cloud Infrastructure” product using juju charms. This is quite an interesting development. I’ll be sure to share a demo with you folks once it’s ready
Collectd the performance monitoring tool, got itself master and slave charms
Almost every charm was touched to be updated for the juju rename. You can view the list of charms here
The cassandra charm got refactored into a single common script for better code maintainability, plus improving seeding new nodes
You can see a list of needed charms over here. If you’d like to be a charmer (we mean that in the juju sense now is a great time to jump in and start playing with juju writing your own charms
Visit us on #juju on Freenode IRC, and the helpful juju community will surely help you answer any questions you may have with either juju, or with writing new charms. You can certainly ping me (kim0) if you’d like to chat a bit about juju or ubuntu cloud in general.
There are a couple of scenarios that we’re focused on at the moment, where we can offer standardised engagements:
Telco’s building out cloud infrastructures for public cloud services. These are aiming for specific markets based on geography or network topology – they have existing customers and existing networks and a competitive advantage in handling outsourced infrastructure for companies that are well connected to them, as well as a jurisdictional advantage over the global public cloud providers.
Cloud infrastructure prototypes at a division or department level. These are mostly folk who want the elasticity and dynamic provisioning of AWS in a private environment, often to work on products that will go public on Rackspace or AWS in due course, or to demonstrate and evaluate the benefits of this sort of architecture internally.
Cloud-style legacy deployments. These are folk building out HPC-type clusters running dedicated workloads that are horizontally scaled but not elastic. Big Hadoop deployments, or Condor deployments, fall into this category.
Cloud has become something of a unifying theme in many of our enterprise and server-oriented conversations in the past six months. While not everyone is necessarily ready to shift their workloads to a dynamic substrate like Ubuntu Cloud Infrastructure (powered by OpenStack) it seems that most large-scale IT deployments are embracing cloud-style design and service architectures, even when they are deploying on the metal. So we’ve put some work into tools which can be used in both cloud and large-scale-metal environments, for provisioning and coordination.
With 12.04 LTS on the horizon, OpenStack exploding into the wider consciousness of cloud-savvy admins, and projects like Ceph and CloudFoundry growing in stature and capability, it’s proving to be a very dynamic time for IT managers and architects. Much as the early days of the web presented a great deal of hype and complexity and options, only to settle down into a few key standard practices and platforms, cloud infrastructure today presents a wealth of options and a paucity of clarity; from NoSQL choices, through IAAS choices, through PAAS choices. Over the next couple of months I’ll outline how we think the cloud stack will shape up. Our goal is to make that “clean, crisp, obvious” deployment Just Work, bringing simplicity to the cloud much as we strive to bring it on the desktop.
For the moment, though, it’s necessary to roll up sleeves and get hands a little dirty, so the team I mentioned previously has been busy bringing some distilled wisdom to customers embarking on their cloud adventures in a hurry. Most of these engagements started out as custom consulting and contract efforts, but there are now sufficient patterns that the team has identified a set of common practices and templates that help to accelerate the build-out for those typical scenarios, and packaged those up as a range of standard cloud building offerings.
Yesterday the earth (or should I say the cloud) trembled with the rename of ensemble to “juju”. I find the new name to be sexy and cool, and every charm (previously formula) writer automatically becomes a charmer (I like that part ) Apart from that, let’s check out recent goodies that landed in juju since the last report
William Reade implemented more robust machine killing. In case of any errors, machines are still being killed which is important in pay-as-you-go cloud environments
William also adds authentication and unicode support to saving files over webdav protocol, which is needed for the Orchestra integration to support deploying physical systems
Thanks to Jim Baker, the juju command to completely destroy an environment is now more appropriately called “destroy-environment” rather than shutdown. It sounds scarier, which is needed in this case!
Benjamin Saller fixed a bug such that now a charm’s default configuration values are correctly made available to hooks
Benjamin also improves juju’s LXC interaction by writing an LXC wrapper and integrating lxc-clone which helps juju deploy LXC containers (for locally deploying charms to your laptop) much faster by cloning a template LXC container
Kapil Thangavelu has been working hard to improve juju’s openstack compatibility. This allows juju to target openstack (and ubuntu cloud naturally) not only ec2
Kapil also improved juju’s security backend, and progressed the local developer story writing down foundation code that enables a juju user to deploy or test juju charms on the local machine (or laptop if you will!)
Kapil also switched juju’s default AMI image to Oneiric Yay!
Clint Byrum has been working hard to improve juju’s test suite, fixed a bunch of test failures and improved multiple tests as well. Good test coverage is always a sign of a healthy project, and juju is no different
Last but most definitely not least, juju’s God father Gustavo Niemeyer is working hard to bring the world juju’s Charm Store! A way for juju users to quickly search, find, download and use charms that others from the juju community have contributed. Once ready, this will be huge news, trust me
The short version, juju is rapidly progressing, becoming more mature, more secure. The charm store is starting to materialize, a lot of work is going into juju to support deploying to your local machine, or to Ubuntu cloud (openstack based). Exciting times indeed!
The NFS charm is now in a working state, this can be backend for any charms that need to have a shared file system
A whole bunch of charms landed to help deploy an OpenStack cloud from juju! This is quite an achievement, expect a tutorial post soon 😉
Wow! that’s a lot of great news! Juju is progressing rapidly, now is a great time to start playing with juju. If you care about a specific piece of software that does not yet have a charm, this is your chance to be the first one to step up and write one! Hop on to #juju on IRC/Freenode and we’ll all help you
So what do you folks think? leave me a comment, let me know your thoughts