Hi, I just got this issue opened for ansible-bender: https://github.com/ansible-community/ansible-bender/issues/111
Most of the magic which bender does happens in a dedicated callback plugin. Hence my question: is there a supported way to access a dict with all Ansible vars from a callback plugin? If not callback, maybe strategy then?
No, callbacks were never intended to access ALL vars, just to receive
specific events and each one should have the proper information
associated with it. Consider that ALL vars means the full inventory,
every host and every variable associated to that host, on top of any
other variables defined in play, this gets unwieldly fast.
Strategies do have access to vars, but mainly focused on 'current task
+ host' , it is possible to expand that to ALL variables, but I don't
know why you want them again this can be huge and impose both RAM and
processing botlenecks.
Brian, thanks for the reply.
In this case, there will always be only a single item in the inventory
(a container) so I don't worry about scalability/performance right
now.
The workflow I am aiming for here is the following:
1. Write a playbook
2. Stuff container image metadata into vars
3. Build the image (`ansible-bender build the-playbook.yaml`)
It can look like this:
- hosts: all
vars:
user_name: user
home_path: /home/{{ user_name }}
ansible_bender:
base_image: fedora:29
target_image:
name: my-fancy-image
environment:
USER: '{{ user_name }}'
HOME: '{{ home_path }}'
working_container:
volumes:
- '{{ playbook_dir }}:/src:Z'
tasks:
In order to allow recursive variables, bender needs to process the
variables using Ansible: so it runs ansible-playbook just to dump all
the vars so they can be referenced. In the case above, all the
variables under ansible_bender need to be rendered.
There was also a suggestion to use the Ansible python API (namely
VariableManager), but given the fact that the API is not stable, I'm
not too excited on using it.
Tomas
So this is a very corner case to support, not something I think we
should do in main code, since 'single inventory' host is the
exception, not the rule.
As for running the playbook to get vars used, this might be misleading
as the vars defined and used can change dynamically per run, so it
will only work if you purposefully avoid generating any variable
dynamically.
I would not say the API is unstable, just that it is not for public
consumption, so we make no guarantee that we won't change it tomorrow
to fit our needs.
So this is a very corner case to support, not something I think we
should do in main code, since 'single inventory' host is the
exception, not the rule.As for running the playbook to get vars used, this might be misleading
as the vars defined and used can change dynamically per run, so it
will only work if you purposefully avoid generating any variable
dynamically.
Yes, it's definitely a hack, but that was the best I could think of.
I would not say the API is unstable, just that it is not for public
consumption, so we make no guarantee that we won't change it tomorrow
to fit our needs.
What would you suggest then? Should I pursue the API then and test
extensively against multiple versions of ansible? From my PoV, that
should be actually okay since I have to do patch releases usually when
there is a new release of buildah which changes behavior bender relies
on.
Thanks, Brian!
Tomas
I don' t know, it feels like you are trying to force a workflow
AGAINST the base design, at that point i would suggest a) change the
workflow or b) use a different tool that actually supports that
approach