RhodeCode 3 Enterprise – Self-Hosted Source Code Repository Review

Written by William Roush on April 13, 2016 at 3:07 pm

Review from long-term end-user and administrator of multiple RhodeCode installs since version 1.x.

Disclaimer: I’ve been a long time fan of RhodeCode and have talked with Marcin Kuzminski (main developer) multiple times.

RhodeCode 3 Enterprise

Installation

First problem I ran into was not getting the validation e-mail, seemed to hard bounce off my anti-spam, ouch, a password reset link made it through though and I got my download. You’ll have to have Python installed first, additionally do NOT rename the file, the installer will get crabby (which wget gladly renames it due to redirects all over by the RhodeCode site):

Whoops

After that you just follow the quick start docs.

Installer enforces that you run it as a non-privileged user (good) doesn’t check for dependencies (bad), so on a clean net install of Debian 8 will crash if it’s missing: sudo and lbzip2, only way you can tell this is if you read the error logs, you’ll also get a totally unhelpful “file not found” when the service user’s home directory is missing/or not writable (Marcin says they’re fixing this though).

After that you’ll install your RhodeCode VCSServer and Enterprise components, these went pretty painlessly with additional packages downloaded from RhodeCode’s servers.

Licensing

RhodeCode has free licensing for up to 25 users (prior this was 20), after that you need to pay up. Currently the price for <100 users seems to fluctuate around $5/seat/person, which isn’t too bad (better than Github, worse than Bitbucket).

I’ve been keeping an eye on their pricing model for awhile, they’ve had anything from $13/user/platform (svg, hg, git) which was pretty rough, to the ability to not pay for support (only updates) which was like $2/user/mo, but they dropped that option sadly. I think the ~$5/user/mo is a good compromise even if it’s more expensive than some cloud providers.

For less than 25 users they also offer support for pretty low per seat pricing currently, a cool option, though I’m kind of always of the opinion if you need lots of support and can’t be self-sufficient outside of reporting bugs: go cloud.

Features

RhodeCode pretty much covers all the bases and includes the following:

External authentication (LDAP, Crowd, etc.)
Repository groups
Gists (public, private, expiration, all the good parts)
Code review (via pull requests)
Forking
Server-managed merging (like GitHub’s auto-merge)
Repository statistics

User Experience

A clean look for 3.0

The whole user interface has been cleaned up with a much sharper look, though a lot of the options are still in the same place they’ve always been (good for old RhodeCode users/admins, though some workflows had pain points).

Everybody gets lots of white space

A lot of white space seems to have been added though, feels like a lot of screen real estate is wasted. This is really obvious between various sections of the site.

The old statistics we’re used to

Nothing really new from the statistics features from the older versions, they’re nice to have but nothing much that is useful.

A bunch of commits

Commits are easy to read.

A terribly formatted readme file

White space issues plague the ReadMe file, taking most of the screen with text much smaller than how it looks on GitHub.

RhodeCode has support for inline and side-by-side diffs when reviewing code, pretty slick layouts that I enjoy.

This… is a journal page.

Journal layout leaves a lot to be desired — but at least they have RSS feeds.

RhodeCode still kind of suffers (in my opinion) from code reviews being nothing more than pull requests, which without and workflow management leaves a lot for anyone that needs more than the absolute basics for code review.

Performance

Everything is much faster than it was, however I’m only able to test it at a somewhat smaller scale than the deployments I’m having trouble scaling on.

As I understand it one of the largest changes for 3.0 was to break everything out and improve the speed of everything, that seems to have done the trick.

However things like statistics still seemed to take an awfully long time to run, not sure if it’s low-effort or

Repository Management

The tools for managing repositories haven’t changed really outside of just somewhat cleaner layouts. You still struggle from the fact that forks will likely clutter up your system, though the addition of “personal groups” somewhat helps, with this you can attempt to mimic a GitHub-like structure.

Overall

The system runs better and is visually more appealing than it was before, and I’m glad licensing has seemed to mellow out at a much more reasonable rate than it was earlier in the RhodeCode 3.0 releases. As much as I loved Gogs, I really need Mercurial support and RhodeCode really hits that sweet spot well.

The only downside is that it’s really hard to compete with the likes of super-cheap cloud providers like BitBucket, though it beats the pants off of Github’s Enterprise pricing (and under some conditions, their cloud… if you can’t fit everything under a smaller organization setup).

Exchange IMAP Over SSL Not Working

Written by William Roush on April 13, 2016 at 2:52 pm

Getting any of the following messages?


openssl s_client -connect [server]:993 -crlf
CONNECTED(00000003)
62604:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52.40.1/src/ssl/s23_lib.c:185:


openssl s_client -connect [server:993 -crlf
CONNECTED(00000003)
write:errno=54

While attempting to fix IMAP login issues for JIRA’s service desk e-mail to ticket integration, I came across this on my Exchange server:


Get-ServerComponentState -Identity [servername]

Server Component State
------ --------- -----
...
[Servername].domain.local ImapProxy Inactive
...

Solution was simple: enable the ImapProxy:


Set-ServerComponentState -Identity [servername] -Component ImapProxy -Requester HealthApi -State Active

Unable to revert snapshot: “the vendor of the processors in this machine is not the same”

Written by William Roush on April 6, 2016 at 5:24 pm

Warning: This is not supported by VMware, not recommended and I am not responsible for any data loss related to trying this. Snapshots are not backups and you should not rely completely on them. If you’re willing to risk data loss this may however save you… Have backups of the VM’s current state before attempting to do any of this.

On this Serverfault post a user is confused due to EVC configuration. For most people EVC only has to do with clusters and vMotion, however if you snapshot a running VM the VM’s CPU feature flags are set depending on the EVC settings of the VM. So a cold migration may leave you unable to revert the snapshot with the following error:

feature requirements of this virtual machine exceed capabilities of this host’s current evc mode

the vendor of the processors in this machine is not the same

We’re going to go ahead and try to take a live VM snapshot and convince VMware it’s a powered off snap. Sadly in my lab I do not have an EVC enabled cluster up with differing hardware so we’re going to take the best swing we can at it. We’re going to start with a powered on Windows VM, snapshot it while it’s powered on and attempt to remove all traces that the snapshot was taken while it was powered on so hopefully those sticky EVC settings won’t stick.

So we’re going to try to trick VMware into thinking the VM was powered off when the snap happened. There are 3 major differences in these files:

SnapshotTest.vmsd – A ‘snapshot0.type = “1”‘ line that denotes it’s a powered on snapshot
SnapshotTest-Snapshot1.vmsn – Additional binary data in the snapshot config file, may be related to state, likely has CPU flags in here somewhere
SnapshotTest-Snapshot1.vmem – The dump of the RAM onto disk.

The easiest way to attempt to do this is to open up the .vmsd file and remove the type line, and remove and re-add the VM to your inventory, this will trick the hypervisor into thinking the snapshot was powered off and won’t load the vmem file.

However I cannot test CPU flags mismatching in my lab, it’s entirely possible that the vmsn file will still conflict, which would require you to do some file surgery with a powered-off snap file as you base file (very risky).

Deleting the snaps will remove the vmem file even if the vmsd file has been updated to declare the VM as “powered off” during the snap, so cleanup should be easy (always check though, we’re doing funny stuff to VMware).

Cannot Consolidate Disks on VMware

Written by William Roush on April 6, 2016 at 1:27 am

Due to the error: “Unable to access file since it’s locked” details may say something like:

An error occurred while consolidating disks: msg.fileio.lock.
Consolidation failed for disk node ‘scsi0:1’: msg.fileio.lock.
Consolidation failed for disk node ‘scsi0:0’: msg.fileio.lock.

Make sure your VM doesn’t have it’s disks mounted in another VM, in this case our Veeam virtual machine did not release the disks when it was done backing it up for some reason, removing the disks allowed us to consolidate the VM.