# Can callback plugin access all Ansible vars? **URL:** \ **Category:** Ansible Developer\ **Created:** [April 12, 2019, 1:04pm UTC](https://forum.ansible.com/t/can-callback-plugin-access-all-ansible-vars/30104 "2019-04-12T13:04:35Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![ttomecek](https://avatars.discourse-cdn.com/v4/letter/t/3ab097/32.png) [@ttomecek](https://forum.ansible.com/u/ttomecek)\ **Post date:** [April 12, 2019, 1:04pm UTC](https://forum.ansible.com/t/can-callback-plugin-access-all-ansible-vars/30104/1 "2019-04-12T13:04:35Z")
Hi, I just got this issue opened for ansible-bender: [https://github.com/ansible-community/ansible-bender/issues/111](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? ---
**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\ **Post date:** [April 23, 2019, 1:40pm UTC](https://forum.ansible.com/t/can-callback-plugin-access-all-ansible-vars/30104/2 "2019-04-23T13:40:47Z")
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. ---
**Author:** ![ttomecek](https://avatars.discourse-cdn.com/v4/letter/t/3ab097/32.png) [@ttomecek](https://forum.ansible.com/u/ttomecek)\ **Post date:** [April 23, 2019, 3:00pm UTC](https://forum.ansible.com/t/can-callback-plugin-access-all-ansible-vars/30104/3 "2019-04-23T15:00:37Z")
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 ---
**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\ **Post date:** [April 23, 2019, 8:30pm UTC](https://forum.ansible.com/t/can-callback-plugin-access-all-ansible-vars/30104/4 "2019-04-23T20:30:46Z")
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. ---
**Author:** ![ttomecek](https://avatars.discourse-cdn.com/v4/letter/t/3ab097/32.png) [@ttomecek](https://forum.ansible.com/u/ttomecek)\ **Post date:** [April 24, 2019, 9:30am UTC](https://forum.ansible.com/t/can-callback-plugin-access-all-ansible-vars/30104/5 "2019-04-24T09:30:34Z")
> 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 ---
**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\ **Post date:** [May 1, 2019, 4:20pm UTC](https://forum.ansible.com/t/can-callback-plugin-access-all-ansible-vars/30104/6 "2019-05-01T16:20:39Z")
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