Just got back from Fudcon Blacksburg. As always, it was a great time. Arrived after driving down (10 hrs) Thursday evening and crashed quickly after checking into my accommodations (The Inn at Virginia Tech). Friday, the first day, was hackfests, I attended the Fedora Infrastructure meeting and held a few sessions around Aeolus where I talked with passer by's about the project, my Snap subproject and what people were looking for out of an open source IaaS cloud abstraction platform. Specifically at FUDCon I aimed to find out how people wanted to interface w/ the cloud on the Fedora desktop and how they wanted to use the Aeolus stack. We ended up modifying Snap a little to add some command line options and began
messing around w/ mycloud a c level cloud computing API I started throwing together to meet people's needs. Dinner that night was at a good indian place.
The second day was the barcamp sessions, I volunteered to do another session on Aeolus, which went well, there were plenty of newcomers interested in the projects and I was able to share what was in development and upcoming things on the platform. After lunch several of us from the ruby-sig met to hold the now traditional ruby-sig meeting at FUDCon (we held one in Toronto, one was held in Milan, and now this was the third at Blacksburg). We got alot done including:
- tested out the new Ruby 1.9.3 repository (messed around w/ getting Aeolus working on MRI 1.9.3)
- discussed updates to the new packaging guidelines, and updates to the the ruby stack
- looked into possibly using macros to assist w/ building gems for multiple ruby interpreters on Fedora (jeroen volunteered to start investigating thing one, this would be a feature coming furthur down the pipeline)
- discussed the rvm / bundler ecosystems, and again how to drive and market the Fedora philosophy of a single supported stack while delivering the ultimate development platform for the ruby-community
- looked into continuing building tools and applications which to enhance the Ruby experience on Fedora, I volunteered to build a isitfedoraruby website (akin to itisruby19.org) to demo and highlight fedora on ruby and to start reaching out to the cloud-sig and other Fedora communities to promote and highlight the product/platform.
- continuing to extend / expand / improve gem2rpm, polisher, and other gem/rpm interoperability tools
Next I attended the session on OpenStack, a popular build-your-own-cloud platform (one of the platforms supported by deltacloud) and learned a bit more about the internals and how it is constructed. Finally the lightning talks session was the last on Saturday, and a must for any FUDCon attendee. There were many pitches, including several for new fedora components including hosted instances of mock infra apps, a discussion on what motivates and how to drive open source contributions, a demonstration on how to inject code into running Python processes using "parasite" by lmacken, an overview of foss@rit by remmy dekaukusburg and the narcissus web visualizations by ralph bean. I ended up pitching mycloud and snap again as well as my own Nethack Encyclopedia project, inviting fellow explorers of the mazes of menace to bring the guide :-)
FUDPub was fun, as always a good time, featuring bowling and lots of tastey food and held at the Blacksburg student center this time around.
I'm writing this from my hotel room Sunday morning as I pack up and prepare for the 10hr drive hack. Overall a great time, have plenty to keep me busy going forward, and am looking forward to the next FUDCon!
Alot of great development on Snap! recently. Here are some updates (see the commit log for the full list):
- incorporated full test harness
- many documentation improvements / fixes
- many code cleanups / optimizations
- starting adding ability to migrate snapshots between OS's (for example Ubuntu to Fedora and vice-versa)
- pushed snap into Fedora! (simply install via 'yum install snap' on Fedora15+ and RHEL6, should be pushed into Debian / Ubuntu soon)
Stay tuned for more updates!
I had such a great time at the last FUDCon I attended, Toronto '09 that I decided to return for Blacksburg '12 this upcoming January 13th-15th in Blacksburg, Virgina. Some of you may recall, during the last FUDCon, I gave a presentation on deltacloud, the core component of Aeolus the Open Source Cloud Computing API.
Alot of great work has went into the project over the last couple of years, and I've decided to submit a few hackfest proposals around using some of the tooling in unique ways. With the first proposal, I aim to go over the various projects that exist under the Aeolus umbrella, and use them to build some simple tools to deploy and monitor cloud provider instances in interesting ways. With my second proposal, I intend to take my subproject Snap (the modular system snapshotter for Fedora/Ubuntu/Windows/etc) and expand it with more custom snapshot targets. I have a bunch in mind, but I'm more than eager to help anyone write a plugin to take a snapshot of their own custom software (these are very easy to write and integrate into the project).
In any case, the conference should be a really fun time as always, and I'm really looking forward to it! Hope to see you all there!
I've added Windows support to Snap, now making it possible to take snapshots of a Windows machine using the same simple tooling as with Linux. Thus it is now possible to move both Windows and Linux instances across disparate VM hypervisors and cloud providers. You may download the windows installer here
Snap not only permits moving an instance between any two generic hypervisors and/or cloud providers, but between any physical or virtual machines as well as well as taking and restoring generic system snapshots.
Stay tuned for more updates!
In the past when evaluating cloud providers, one had to to make a critical decision right up front, to select the provider that offers the features needed at a price that is agreeable to the end-user. If the provider changed their terms of service and/or pricing scheme, the sysadmin/developer was more or less stuck with their choice, unless they made the painful effort of manually migrating all software and data to another provider. Well not anymore.
I'm pleased to announce that with the assistance of Aeolus, Red Hat's Open Source Cloud API, and Snap! a system snapshotter and restoration utility (started as my Masters project in '07), it is now possible to migrate cloud instances of any type across cloud providers (currently supported distros are Fedora, Ubuntu, Debian, RHEL, and CentOS with more and Windows support in development / coming soon).
For details, see the following step-by-step guide complete w/ screenshots of how to migrate instances between Amazon EC2 and Rackspace (this will work for migrating instances between any cloud providers supported by deltacloud, the core Aeolus component/api). Everything will be migrated from the source instance to destination on the fly (no instance downtime), from package repositories and installed software, to files modified outside the package management system, to services and their configurations, etc.
The machine I was orchestrating the migration from was my local F15 laptop. I setup environment variables in my bash profile corresponding to the following:
- $EC2_USERNAME: my ec2 access key, retrieved from the AWS security credentials screen
- $EC2_PASSWORD: my ec2 secret access key, also retrieved from the AWS security credentials screen
- $RACKSPACE_USERNAME: my rackspace login name
- $RACKSPACE_PASSWORD: my rackspace API key, retrieved by logging into rackspace and navigating to Your Account > API Access
$ sudo yum install deltacloud-core-ec2 deltacloud-core-rackspace rubygem-deltacloud-client
I then started deltacloud servers for both the ec2 and rackspace drivers (note it is now possible w/ the upstream deltacloud project to use the same server for multiple drivers)
$ deltacloudd -i ec2 -p 3002
$ deltacloudd -i rackspace -p 3003
Next I used the deltacloud client to retrieve information about my running EC2 instance
$ deltacloudc instances index -u http://$EC2_USERNAME:$EC2_PASSWORD@localhost:3002/api
Note in this screenshot, you can see the ec2 instance hostname which I can ssh to (due to the formatting of the field, 'amazonaws.com' has been truncated)
Now I ssh'd into the instance, specifying my keypair previously configured on Amazon when starting the instance
$ ssh -i ~/.ssh/mmorsi-keypair.pem email@example.com
On the cloud instance, I used yum to install Snap. Until the Snap package is accepted and avaiable in Fedora / Ubuntu / other mainstream distributions, I have hosted binary packages in my own yum and apt repositories
$ sudo wget http://yum.morsi.org/repos/15/morsi.repo -O /etc/yum.repos.d/morsi.repo
$ sudo yum install snap
Due to how Amazon handles its cloud security policy (eg through their security groups concept), iptables is not setup on EC2 instances. Snap will by default backup and restore iptables rules, so we have to edit the snap configuration file to remove this backup target
$ sudo vim /etc/snap.conf
Remove the hightlighted content
Before running the snapshot, lets take a look at the options Snap presents us. Note Snap provides both a command line tool and a graphical GTK based one (more on snap coming in a future blogpost)
$ snaptool --help
Now we run the actual snapshot
$ sudo snaptool --backup --log-level verbose --norepos --packages --nofiles --services
We pass in --backup to perform a backup operation instead of a restoration one, specify verbose output with --log-level, and configure the snapshot targets. Snap offers a very modular / extensible plugin system in which targets to backup / restore can easily be defined, and operating system specific backends to those targets implemented. In our case we opt to backup the packages installed on the instance as well as the running services. We do not need to backup any package repositories as we are only using stock fedora software and no extra files are required (--services will backup the files required for those services to run)
This produces a snapshot in /tmp/snap-shot.tgz (the location of this can be configured by specifying --snapfile to snaptool). Back on our host system, we scp that file locally
$ scp -i ~/.ssh/mmorsi-keypair.pem firstname.lastname@example.org:/tmp/snap-shot.tgz .
We can easily inspect the snapshot as it is a tarball (snap also supports snapshot encryption/decryption, protecting the contents of the tarball)
$ tar tzvf snap-shot.tgz
Next we goto launch a new instance on our destination cloud, Rackspace. To do this we first view the images available to base our instance off of
$ deltacloudc images index -u http://$RACKSPACE_USERNAME:$RACKSPACE_PASSWORD@localhost:3003/api
We've highlighted an image matching the OS out our source instance (note it is theoretically possible to restore the snapshot on a completely different OS! I have yet to try this out yet though so no guarantees)
Now we spin up a new instance using the selected image as the basis
$ deltacloudc instances create -u http://$RACKSPACE_USERNAME:$RACKSPACE_PASSWORD@localhost:3003/api --image-id 78
We see the ip address of the instance, which we can SSH to, right from this output. Once the instance is started (usually within a minute from my findings) Rackspace sends an email containing the root password
Before logging in, we scp our snapshot over to the new instance
$ scp snap-shot.tgz email@example.com:~/
We now ssh into the new instance
$ ssh firstname.lastname@example.org
We use the same wget and yum commands as above to install Snap
# wget http://yum.morsi.org/repos/15/morsi.repo -O /etc/yum.repos.d/morsi.repo
# yum install snap
Now we restore the snapshot, again using snaptool
# snaptool --restore -l verbose --snapfile snap-shot.tgz
Finally since the EC2 security groups mechanism is different than the standard iptables solution, and we weren't able to simply backup/restore the firewall policy (as Snap does by default), we need to open port 80 for http in our firewall. We use the text based firewall manager that ships w/ RH based system to do so