Skip to content

Conversation

@SJLC
Copy link
Contributor

@SJLC SJLC commented May 3, 2016

Fixes #2

Migrate from ansible's pre-1.9 privilege escalation mechanism
to the current mechanism:

  • Switch 'sudo:' to 'become:' in playbook
  • Remove '-s' from ansible-playbook command-line

Fixes nylas#2

Migrate from ansible's pre-1.9 privilege escalation mechanism
to the current mechanism:

* Switch 'sudo:' to 'become:' in playbook
* Remove '-s' from ansible-playbook command-line
@spang
Copy link
Contributor

spang commented May 25, 2016

Thanks for contributing! Does this break compatibility with ansible < 1.9? Is there a way we can fix this for 1.9 without breaking backcompat?

@SJLC
Copy link
Contributor Author

SJLC commented May 26, 2016

Maybe...

There could be some check on ansible_version to pick whether to execute 'sudo' or 'become' version, though the check on ansible_version wouldn't distingish between a really old version and ansible 2.0 due to a bug ( ansible/ansible#11545 )

On the other hand, ansible 2.0 has the 'sudo' backwards compatibility working again, unlike 1.9 ( #2 ), so perhaps the policy could be to use sudo if ansible_version < 1.9 or ansible_version undefined.

On the third hand, is backward compatibility even useful in this specific instance? ansible-test uses pip to install ansible, not the package manager, and without locking it to a specific version. Thus the newest stable ansible is always used for tests, and nowadays that is never going to be a version that lacks 'become' support.

So do you want to uglify things for a situation that won't be encountered with the current install strategy? If not, I could just re-base what's here now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants