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
On Tue, Apr 23, 2019 at 3:40 PM Brian Coca <bc...@redhat.com> wrote:
>
> 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 Coca
--
You received this message because you are subscribed to the Google Groups
"Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-devel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
