Fix pip installation and remove azavea.pip ansible role

[KlaasH]

Overview

The URL of the 'get-pip.py' script now has a version number, which broke provisioning. In two places, actually, since we need pip at the very beginning to install Ansible inside the VM, then we also had the Azavea pip role being used by the Azavea aws-cli role.

Having a second place where we install pip, especially one that's very simple but not very actively maintained, isn't worth it. So this clones the aws-cli role into a local role and drops the dependency on the pip role. Since pip is installed in the Vagrantfile provisioning, it will always be there.

Also, Ansible still wants to use Python 2 by default, but that's no good. Not that the VM is a user-facing environment, but we already upgraded most of this project and it doesn't make sense to keep using Python 2 if we don't have to. This makes sure Ansible and the AWS CLI both get installed in Python 3.

Notes

• I had planned to roll upgrading the AWS CLI for issue #823 into this, since I was already changing the role that installs it, but I backtracked on that since there's no PyPI package for AWS CLI v2, so switching to that will require a more substantial change, not to mention the need to look for places where breaking changes could affect us.
• UPDATE: I originally said this would reprovision an existing VM without issues, but actually with the ansible_python_interpreter group var in place it crashes because it can't find pip3 to check whether awscli is installed. I don't know of a way to get the pip installation in the Vagrantfile to re-run. It's possible to work around this and preserve an existing VM by manually installing pip3, i.e. vagrant ssh -c "sudo apt-get install -y python3-pip"

Testing Instructions

• UPDATE: copy the new line (ansible_python_interpreter: "/usr/bin/python3") from deployment/ansible/group_vars/all.example to deployment/ansible/group_vars/all

• ~Running provision again on an existing VM should work with these changes, but they mostly won't actually take effect. The ansible_local section in the Vagrantfile will detect that Ansible is already installed, so it won't try to install it again, and the aws-cli role will upgrade the version, but using the existing pip, which is Python 2. But that's fine.~ UPDATE: see note above.

• If you do vagrant destroy and build the VM again, it should now be free of pesky crashes.

• If you ssh into the new VM, you should find that pip and aws both use /usr/bin/python3, which is Python 3.5.

• Once the VM is up, running ./scripts/update and ./scripts/server inside it should work as before.

Checklist

• [x] Add entry to CHANGELOG.md

Resolves #827

[kevinearldenny]

@KlaasH I'm still running into some issues here when trying to build a new container locally - see logs attached setup.log

[KlaasH]

I forgot about the new group_var. I've updated the comment above.

It would be nice if there were a tracked all file and the environment-specific variables lived in a different tracked-example/untracked-file pair. But probably transitioning to that would be overkill for a file that changes pretty seldom and only causes some mild temporary confusion when we miss copying over a change.

[kevinearldenny]

Okay, it looks like after copying over the ansible_python_interpreter variable this is working good. 👍