We plan to switch the default way to run ansible and deprecate the current one, as it seems to be more ansible user friendly and less forman like way.
We have gathered feedback that current way is quite confusing for ansible users. I am sharing a roadmap and I’m going to share the progress in this thread. Please share any thoughts or concerns you have about the process.
The high level roadmap is quite simple:
1.23 - make the ansible-runner default for new comers
1.24 - migrate everyone to ansible-runner and deprecate “ansible-playbook”
In more detail though, we have got a lot of ground work to make sure the transition is smooth.
1.23:
ansible runner provides bionic deb packages (to have all supported platforms covered),
[*] test the working ansible-runner at least on RHEL and Debian systems,
[*] make smart-proxy-ansible depend on ansible-runner package,
[*] installer is installing ansible-runner on smart-proxy,
[*] document deb builds in ansible manual - Installing Ansible Runner — Ansible Runner DocumentationAdd debian install documentation by ezr-ondrej · Pull Request #316 · ansible/ansible-runner · GitHub
[*] switch the default value of the setting to use ansible-runner
try to get STDOUT inside the ansible callback - if not, runner might be the only way to provide the STDOUT
Send the stdout with the config reports and visualize it.
1.24:
[*] migration switching the value for everyone
drop ansible implementation settings, remove the code from foreman_ansible_core
specify the minimum version of ansible-runner that’s supported
It is done through REX. The execution gets delegated to a smart proxy the same way we do for REX, from there the proxy runs ansible-playbook with right parameters for each host.
No, or at least we don’t use it as a daemon. We use it the same way as ansible-playbook, but the interface is different.
The main reason for using runner is that is where the Ansible team is attempting to create a strong API which will is ensured to not break release to release. Calling ansible-playbook does not have that guarantee.
That could be achieved even through playbook I believe, you can define an inventory in the playbook, so it behaves the similar way as we want to achieve by ansible-runner.
Yes, I was more referring to what these two differences mean as standing today. Also probably worth mentioning the flip side, using ansible-runner will mean the host statuses for single job will be updated at once at the end and it won’t be possible to cancel the run per host. But that’s not a big lose IMO comparing to the benefits.
Hello,
what happens with ERB vars???.
Foreman render yor ERB job template with the values of the first host to run. Then create /tmp/xxxxxx/project/playbook.yml with that rendered job template so you are going to use the host.shortname value of the first host with the 2 host, the 3… Perphaps I’m not seeing something… but its a big problem that means you can’t use Host Specific Variables.
am I right???
I have been a problem with this (temporary workarounded) explained with more detailed at:
Yes , i know you can change erb render of foreman host spefic vars for ansible hostvars but its confusing that you can use something that are going to generate problems.
Ansible-runner its a very great and big change, i answer past year for something like this to get the same behaviour at foreman ansible templates as directly in ansible (one real ansible execution for all host against one execution per host like with ansible-playbook old foreman aprox.
Some documentation and information would be appreciate!!!
