Updated to Ansible 2.4, deploys broken, now what?

Much as I love Trellis sometimes I feel like I’ve missed an announcement.

New Trellis install prompted me to update to Ansible 2.4, that’s fine, but now older projects won’t Provision/Deploy. Is there a guide to what exactly needs to be updated to correct this?

3 Likes

We definitely could do a better job at communicating things. Sorry :frowning:

Short answer before I head to bed:

You can use pip install ansible==2.3.2.0 to switch back to the older version. If you want to avoid switching between Ansible versions you’ll need to upgrade your older projects with @fullyint’s changes for Ansible 2.4 compatibility.

8 Likes

This was more an oversight than anything else. We (naively) forgot that making someone install Ansible 2.4 would obviously cause problems if you had multiple projects on different versions.

Requiring a new version isn’t a big deal in itself, since we check for the version. But somehow this never really came up before on past version bumps.

1 Like

I wonder if it would be possible / worthwhile / prudent / whatever to run a check for Trellis version, and just install and run the appropriate Ansible version in a virtualenv?

Maybe the virtualenv would get activated and deactivated at some clearly defined point - like vagrant up and vagrant halt, for example.

It would require the user to have Virtualenv installed, but I feel like that’s one that is good to have installed regardless, if you’re doing anything involving Python.

If it sounds like something worth pursuing, I wouldn’t mind trying to put something together.

2 Likes

We can sort of already have that, since Vagrant supports ansible-local now, basically installing Ansible on the virtual machine and running everything from there. The difference would be that if you want to provision or deploy your project you would have to SSH into the box and run your commands there.

I just ran into this myself and wanted to post back to emphasize that Virtualenv really is handy for this sort of thing. The gist of it is:

Install Virtualenv- sudo pip install virtualenv

Create a directory, anywhere, call it whatever you want. I called mine “virtualenvs”. I made mine in my home directory, and made it a hidden directory. mkdir ~/.virtualenvs && cd ~/.virtualenvs

If I want to create an environment to run Ansible 24.0.0 I could run (from my .virtualenv directory) virtualenv ansible_24.

This command creates a directory called “ansible_24” and installs a complete Python environment there, separate from your system environment. It’s not large, we’re talking 75 Mb for a virtualenv w/ Python, pip and Ansible.

Now just activate the environment by CDing to it, cd ansible_24 and running source bin/activate

You’ll know the environment is active because your prompt will show the name of the active environment, so $ /some/dir would change to (ansible_24) $ /some/dir

Once it’s active install the Ansible version you need, pip install ansible (note no sudo needed when in a virtual env)

That’s it. Now any commands ran from that shell will use the active Python environment.

When you’re done run deactivate and you’ll go back to your system environment.

To use again just activate it, so if I were in ~/sites/mysite and wanted to use my other Ansible version I’d run source ~/.virtualenvs/ansible_24/bin/activate and that’s it. Maybe setup an alias for that or something if you want.

If you no longer want the env around it just delete it - rm -rf ~/.virtualenvs/ansible_24.

There’s more to it, like you can specify Python versions and that sort of thing, but for the person with umpteen hundred Trellis installs who just needs to switch back and forth, this should be plenty.

PS. For the ultimate in convenience also install Virtualenvwrapper. There’s a little config beyond the initial Pip install, but it’s just a few lines added to your zshrc, or bashrc, or whatever.

With Virtualenvwrapper setup you just run mkvirtualenv some_env_name from anywhere on your system and it handles the rest. Then to use it you just run workon some_env_name and it handles it.

If you really want to nerd out you can configure your terminal to run workon whenever you CD to the specified directory.

Hopefully this is helpful. I’ve been digging into Python a bit over the past few months (it’s awesome) and have found virtualenvs to be pretty much necessary.

11 Likes