Applier processes variables too early, making it difficult to use a pre-role for discovery purposes

[etsauer]

I would like to have the ability to do discovery at some phase of an applier run. The purpose of this would be to be able to pull some values out of the kube api and use them as parameters to templates later in the run.

For example, let's say I have a pre-role that does this:

- name: Get Cluster Info
  k8s_facts:
    api_version: config.openshift.io/v1
    kind: Infrastructure
    name: cluster
  register: cluster_info

- name: Set Cluster Info Facts
  set_fact:
    infraid: "{{ cluster_info.resources[0].status.infrastructureName }}"

Then in my applier inventory I pass this infraid to a template:

  - name: MachineAutoscaler zone a
    template: "{{ inventory_dir }}/../templates/machineautoscaler.yaml"
    params_from_vars:
      CLUSTER_ID: "{{ infraid }}"

The problem with this is the fact that when we execute a loop over our openshift_cluster_content dictionary, the execution of the loop processes all of the variable templates in our dictionary. So by the time the pre-role tasks run, the "{{ infraid }}" template has already been evaluated.

I would like to propose we rethink how we execute this looping so that we can do "just in time" jinja processing.

This will also come into play with #134

@oybed @tylerauerbeck @jkupferer

[jkupferer]

Just put in a PR to show the beginning of a fix:

https://github.com/redhat-cop/openshift-applier/pull/138

The issue appears to be in how with_items/loop processes variables. It is odd, but if we just switch from looping over the content list to looping over the list length then the variable evaluation is deferred as would be expected. This does break the use of filter_applier_items, we would need to figure out how to reintroduce this functionality.

[oybed]

Just as a FYI as it's related - I believe I hit some of this while using the get_resources role I created: https://galaxy.ansible.com/oybed/openshift_get_resources

[jkupferer]

I took a stab at how to re-implement filter_applier_items functionality as filter_applier_item. I'm not familiar enough with applier to feel confident testing...

[jkupferer]

@etsauer and I went over this and found a couple issues. It looks like it is good to go now. Testing the PR in travis failed on one task that looks unrelated to the code changes.