Support for ubuntu 16.04 (Xenial)

[vrocha]

Among the most important changes are:

• We no longer need to pin our pip version. Actually, 8.1.1 break the build, we need 8.1.2.
• locale is not an argument for postgres_database.present any more.
• There is no such thing as a sudo service any more, and no need for it.
• Some fail2ban specific nuances that sort of worked out.

Running the highstate for the first time throws two errors, we need to run it twice to actually get a deployment working. I think we could get it to deploy on a single go but we are used to having to run it more than once now.

[dpoirier]

Will projects that still use Ubuntu 12 or 14 be broken by these changes?

[vrocha]

@dpoirier The answer to your question is yes partially and this is something Mark mentioned to me and i will find some time to test/fix as needed.

[vkurup]

I confirmed that pip version 9.0.1 won't work with Ubuntu 14.04, at least with Salt 2015.5.8. In another branch (vk-xenial), I added a check to see if we're on an OS version < 16.04, and pin pip only in that case. That seems to work for old OS versions. I just read through #130 where Dan recommended checking the salt version, rather than the OS version, and that makes sense to me, so I'll investigate trying that change.

The other stumbling block is that I haven't yet been able to get this to work on 16.04. I initially had trouble getting salt installed and I think there is an incompatibility between 16.04 and Salt 2015.5.8. I've been able to get salt 2016.3.2 installed, but then when I try to run the deploy, I get a Jinja error in project.web.balancer which I haven't figured out yet:

- Rendering SLS 'base:project.web.balancer' failed: Jinja variable list object has no element 0

[kmtracey]

For a project where we are using 16.04 already we have Salt 2016.3.2 (Boron) being reported so hmm...let me know if you need access to that working project to see what might be different...

[vkurup]

The specific error comes from these 2 lines:

1. https://github.com/caktus/margarita/blob/develop/project/_vars.sls#L4
2. https://github.com/caktus/margarita/blob/develop/project/_vars.sls#L16

Ubuntu 16.04 no longer has an eth0 default interface, at least in the AWS images that I provisioned. It's labelled ens3 (or something like that). I think the project @kmtracey mentioned got around this (inadvertently or not) by setting up an ElasticIP because I see this in the console for that instance:

But that entry is blank for an instance that I create from an Ubuntu 16.04 AMI.

I don't know the best general way to fix this.

[vkurup]

Ugh... and now I've created a few more EC2 instances and these all DO have eth0 defined...

[vkurup]

OK, I've created and destroyed a few more instances. All the t2.small ones had eth0 and all the m4.large ones did not. I think we'll need to make the template accomodate both situations... somehow

[jbradberry]

@vkurup Ansible has the concept of a default ipv4 interface, which I wound up having to use in tequila-postgresql for this very reason. Presumably Salt will have something similar?

[jbradberry]

https://tedops.github.io/how-to-find-default-active-ethernet-interface.html

[vkurup]

Thanks @jbradberry! I'll give that a shot.

[vkurup]

Thanks! This work is now in version 2.0.0 via #147.