Keep an eye on HHH-docker

[nuclearsandwich]

There's an attempt to fork and maintain the docker puppet module we're using to https://github.com/HackerHappyHour/hackerhappyhour-docker

The issue that most affects us at the moment is the outdated repository url, which is surmountable without updated but if the community moves to this fork I think it's sensible to follow.

The maintenance / release request issue: garethr/garethr-docker#699

As ever, thanks to the authors and maintainers past, present, and future, of these modules. We'd all be in a rough state without your contributions!

[LongLiveCHIEF]

I should be finished with this fix tonight or tomorrow. If you have any specific requirements that you want to make sure make it into this fix, let us know here: HackerHappyHour/hackerhappyhour-docker#7

I've got a WIP branch that you can even use to test if need be as I move this work along: https://github.com/HackerHappyHour/hackerhappyhour-docker/tree/7-refactor-package-management

[nuclearsandwich]

Thanks @LongLiveCHIEF we don't currently exercise much of the Docker puppet module except to install Docker for our other services. I think I can allocate some time to test this out early next week as part of some other work.

One issue I saw was that the manage_kernel option fails if using the new default (as of April) AWS Kernel when deploying Xenial on EC2 with an error finding the package linux-image-extra-aws but I think Docker should still be able to run with the base AWS kernel. I don't know whether it's worth adding a special case for it or just documenting that manage_kernel should be false when using the AWS kernel.

Now that upstream supports Xenial on arm64 we'll want to be able to use the puppet module there. I can try to test this

[LongLiveCHIEF]

the updates i made last night will automatically discover any debian release that docker has in their repository, so this should be fixed. I'm having a few issues with getting tests to pass, because I'm using hiera data at the module layer now instead of the old params pattern.

Two questions for you:

• I take it you intend to deploy on AWS? (i need to work out a good test suite for it if so)
• Are you able to use puppet 5?

I was planning on dropping support for older versions of puppet, especially if we see any activity in puppetlabs/docker.

I opened an issue there asking them to state their intentions around maintaining that, and if they say yes, then i'm going to continue down the path of puppet 5 only in hhh-docker. If they say no, i may have to revise that and support EoL versions for a while longer.

[nuclearsandwich]

I take it you intend to deploy on AWS? (i need to work out a good test suite for it if so)

We deploy on AWS but in a pretty vanilla fashion and we use puppet apply with different hiera parameters and puppet modules. Puppet cannot even be re-run in production on one of the machine roles without clobbering data.

I'm not sure what a feasible test strategy would entail. It might be enough to spin up a nano machine running Ubuntu Xenial and the aws kernel, verify that Docker works on in it without any kernel modifications, then mock the kernel name and verify that the manage_kernel stuff is a no-op. But I'll confess to not knowing much about puppet testing practices.

Are you able to use puppet 5?

No. We're using Puppet 3.8 from Xenial with the Future parser enabled. I don't see upgrading being a near-term priority as we've only just made it to Xenial and we don't use a puppet master.