Add support for Ubuntu 14.04

[kevinquinnyo]

I'm working on this right now.

The only weird thing is that in order to keep the same configuration options for ENV variables in the configuration file, I have to do something like this, where RELEASE is a configurable variable just like MCROUTER_VERSION and MCROUTER_SHA:

Dockerfile:

FROM ubuntu:__RELEASE__
# [..snip..]
ENV RELEASE 14.04

But, since FROM has to be the first line of the Dockerfile, we have to use a "templated" variable (__RELEASE__) that we replace in the Makefile:

Makefile:

# [..snip..]
RELEASE = `grep "ENV RELEASE" Dockerfile | cut -f3 -d' '`

.PHONY: all build cp

all: build cp

build:
        sed "1 s/__RELEASE__/${RELEASE}/" Dockerfile | docker build -t mcrouter -
# [..snip..]

I don't know if there's a cleaner way to do this. The above should work but it's kind of hacky. Perhaps a wrapper script for the whole process? I was avoiding that because I thought your use of a Makefile was a clever way to handle the whole build + docker orchestration and wanted to stick to that.

[kevinquinnyo]

So it turns out that this won't work. My lack of Docker experience is to blame. ADD commands won't work as expected when using docker build with STDIN (-) instead of a default Dockerfile in the docker path because with STDIN there is no "context" for the ADD command. My proposed workaround would be creating temporary Dockerfiles in our docker build path, like Dockerfile-${RELEASE} and using the -f option to specify the Dockerfile. Then we could add those to the .gitignore and possibly remove them with make clean? Something like:

Makefile:

build:
        sed "1 s/__RELEASE__/${RELEASE}/" Dockerfile > Dockerfile-${RELEASE}
        docker build -t mcrouter -f Dockerfile-${RELEASE} .

# [..snip..]
clean:
        rm -f Dockerfile-*

Of course if we're doing that, it might make more sense to just have specific Dockerfiles in the repo, especially since there are a few changes that need to be made to make the Dockerfile work for different releases:

Dockerfile-12.04
Dockerfile-14.04
Dockerfile-15.04  # I only care about LTS releases personally so not sure on this

The latter solution would avoid things in the Makefile-generated Dockerfiles like:

RUN if [ ${RELEASE} = '12.04' ]; then # do 12.04 things; else # do '14.04' things; fi

But it would also violate the DRY principle since 90% of the Dockerfile-* would have the same content. Ignoring the DRY issues, I actually think the latter is the cleaner solution, and more docker-esque, but I'm not sure on that.

[bmorton]

These are all very good points. How much of the Dockerfile itself has to change to support 14.04? Is it just the two shell scripts that install dependencies that mention 12.04?

[kevinquinnyo]

facebook/folly#336

I've added an issue in folly for your question in the PR about a ./build/deps_ubuntu_14.04.sh

[bmorton]

So it turns out we don't even need to install folly ourselves since the mcrouter install script already installs it for us. I haven't checked history to see if this was a recent change or if we had just messed this up, but that should simplify this a bit if you're still interested in doing this!

[kevinquinnyo]

Interesting. Yeah that might have been added at some point, I'm not sure either. Speaking of this, since I liked the way you designed building the package -- Makefile + Docker + FPM, I decided to emulate it for an internal repo to build something else (https://github.com/varnish/hitch), and it occurred to me it would be pretty slick to take your package-building idea and make it configurable such that it can build a package for any source available on github via configuration.

Then I found this: https://github.com/alanfranz/docker-rpm-builder -- it only builds rpms, so it's not what we would need, but it looks like a similar concept.

Is mcrouter the only thing in your stack that really needs to be source-compiled and packaged? If so then it's probably not worth the time of making a grand "source-packager" project, but it would probably be a fun project regardless.

I haven't really had time to revisit this since my immediate issue was solved, but I'll get back to this project soon and look into these things.