Archive for June, 2012

Less Obvious Changes in Eucalyptus 3.1

27 Jun 2012

Now that Eucalyptus 3.1 is out at last and we all get to wade through tons of announcements and blog posts, I thought I would mention a few of the changes that have happened since Eucalyptus 2 that you aren’t likely to see in marketing materials.

Why Eucalyptus 2? Most of us don’t get to use Eucalyptus 3.0, so comparing against that wouldn’t exactly be fair, would it? ;-)

Centralized documentation

The documentation for Eucalyptus 2 was strewn about the Eucalyptus website on a number of wiki pages. You had to read all of them to have any hope of ending up with a working cloud.

Eucalyptus 3’s documentation comes in the form of front-to-back PDFs. HTML documentation is forthcoming. You still need to read it all, but it is now in one place so you don’t have to go digging to find it.

The documentation’s source (in DITA format, if you find that sort of thing interesting) is also up on github, so there is now a way to fix errors: just send a pull request.

A new database

Eucalyptus 3.1 switches from HSQLDB to PostgreSQL. Given the number of Eucalyptus users I have seen over time who have experienced problems with HSQLDB’s behavior in the face of faults, I suspect this will make a lot of people happy.

Correct packaging

The RPM and DEB packages for Eucalyptus 2 fail to list a number of important things they depend upon, making the software needlessly complicated to install. In fact, this was so complicated that the popular FastStart distribution became the method of choice for getting started with a new Eucalyptus cloud.

This is no longer the case. Installation now consists of adding package repositories and telling one’s package manager to install a component. No more “install these dependencies first.” No more “download these packages separately and install them.” In fact, short of a script that writes Eucalyptus’s configuration for you, this completely obviates the need for FastStart.

RHEL 6 support

Eucalyptus 2 is supported only on CentOS 5. It also works on RHEL 5, but users of RHEL 6 and friends couldn’t even compile the stuff. That is now fixed; those operating systems now have full support.

A more usable configuration file

Eucalyptus 2’s configuration file jams everything into one huge list. Nothing gives any indication what Eucalyptus components actually care about each option. There is also no indication how options were affected by one’s choice of networking mode.

Eucalyptus 3’s configuration file and documentation break options down by component. For networking-related options, they also list the networking modes in which they apply.

Bugfixes

Eucalyptus 3 fixes bugs. Lots and lots of bugs. So many bugs that release notes cannot possibly list them all. In the future this will be easier, as every future bug report will now go through a new JIRA tracker.

What else?

Those are some of my favorites, but there are lots of other little improvements all over the place. Try Eucalyptus 3 out and see what you think. You may be pleasantly surprised.

Speed Up Merges with Git’s Index

14 Jun 2012

We’ve all been there, running git merge only to have it spew CONFLICT all over the place and quit partway through. But if we already know that every time there is a conflict then all of “our” code that we are merging changes into should take precedence over “their” changes that we are pulling in, git 1.7.3 provides a handy shortcut for that:

% git merge -X ours theirbranch

If “their” changes that we are pulling in should always take precedence instead then things are equally easy:

% git merge -X theirs theirbranch

If “ours” or “theirs” style merges will work, but only for certain files, things get a bit more complicated. But with a bit of background knowledge of how git’s index works we can save ourselves a bunch of work.

The index stores what stage a file is in. Normally, a file’s stage is 0.

% git ls-files -s myfile
100644 4b48deed3a433909bfd6b6ab3d4b91348b6af464 0       myfile

A file with a merge conflict is different because the index actually has three different versions of it: the version that the two branches we are merging most recently had in common, the version on “our” side of the merge, and the version on “their” side of the merge. In git these correspond to stages 1, 2, and 3. This is one reason one has to run git add on every conflicting file before completing a merge.

% git ls-files -s myfile
100644 4b48deed3a433909bfd6b6ab3d4b91348b6af464 1       myfile
100644 5be4a414b32cf4204f889469942986d3d783da84 2       myfile
100644 39c5733494077ae8bc45c45c15a708ffe9871966 3       myfile

Rather than opening up the conflicting file and clearing out the parts that clash by hand, we can instead simply copy the version we want from the index into our working tree:

% git checkout-index -f --stage 3 myfile
% git add myfile
% git commit

Git Pull via Sneakernet

8 Jun 2012

Today I found myself needing to move some commits between two repositories. In general the best way to do this is by pulling changes from one into the other, but in this case the repositories did not have direct access to each other. Rather than copying an entire repository from one machine to another or mucking about with a pile of patches, we can save time by performing the sending and receiving sides of the network-enabled git fetch command by hand.

In the source repository, add the changes we want to move to a bundle that we can copy to a USB stick:

% git bundle create changes.bundle master..mybranch
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 313 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
% cp changes.bundle /media/usbstick

In the destination repository, ensure that we have the commits necessary to use the bundle and then tell git fetch to grab the changes from it:

% git bundle verify /media/usbstick/changes.bundle
The bundle contains 1 ref
7a1d2087f10e6db33e6b4a28e2c427b65238a62c refs/heads/mybranch
The bundle requires these 1 ref
6f5fced94ef76f1b46e259db72ad6fc39c49ba72 
/media/usbstick/changes.bundle is okay
% git fetch /media/usbstick/changes.bundle mybranch
Receiving objects: 100% (3/3), done.
Resolving deltas: 100% (2/2), completed with 2 local objects.
From /media/usbstick/changes.bundle
 * branch            mybranch   -> FETCH_HEAD
% git merge FETCH_HEAD
Updating 6f5fced..7a1d208
Fast-forward
 README |    2 ++
 1 file changed, 2 insertions(+)