Custom jinja Undefined class for handling nested undefined attributes

[agaffney]

SUMMARY

This commit creates a custom Jinja2 Undefined class that returns Undefined for any further accesses, rather than raising an exception. This allows doing something like foo.bar.baz | default('whatever') rather than ((foo | default({})).bar | default({})).baz | default('whatever') when you don't know if all levels of the structure are defined.

This was created as an alternative to #50706

ISSUE TYPE

• Feature Pull Request

COMPONENT NAME

templates

ADDITIONAL INFORMATION

[nitzmahone]

This is technically probably a breaking change, since we're reimplementing . as a null-conditional operator (eg C#'s ?.)... That said, I'm having a really hard time coming up with a scenario that wouldn't have just blown up catastrophically anyway, since you can't try/catch in an Ansible template. Maybe something in a "real" template? Dunno...

I'm a big +1 for the change in behavior, so long as nobody can come up with a scenario where the current behavior actually makes sense (in which case we'd probably have to talk some combination of switch and deprecation warning).

[jwitko]

Huge fan of this behavior change. Like @nitzmahone , I can think of no situation where this would break that isn't already breaking.

[jhawkesworth]

I'd like this too. This is something I've wanted to do in when: conditions and also when using ternary filter in the past. I've added to my list to test.

[dagwieers]

Tested and works fine. My only concern is that people have been doing ugly tricks to circumvent the original behavior that may be bitten by this. (ignore_errors?) But honestly, they deserve breakage :-) This is for the better.

[tonk]

I agree with @dagwieers and I'm a +1 for this. This makes life a lot easier.

[felixfontein]

I guess it should mentioned in the porting guide and changelog. Besides that, +1 from me, too!

[gundalow]

@agaffney Seems like people are happy, though could you please add a changelog/fragment and an entry in the porting guide?

Once you've done that please poke me on IRC and I'll merge ASAP (as porting guides can end up in merge conflicts)

Adding requires changes as currently this has sh1pit

[ansibot]

cc @acozine
click here for bot help

[agaffney]

Added changelog fragment and section in the porting guide

[acozine]

This is a nice addition - I've made some suggestions to make the documentation even better. Thanks @agaffney for the PR.

[s-hertel]

Looks good to me, and adding a toggle if this breaks things for people is a good back-up plan. Here's an example playbook that does change behavior:

---
- hosts: localhost
  connection: local
  gather_facts: no
  tasks:
  - name: test
    command: echo "{{ dict_var.bar.baz | default('test') }}"
    ignore_errors: yes

ignore_errors also prevents templating errors - e.g.

    ignore_errors: yes
    when: dict_var.bar.baz | default('test') is defined

[jamescassell]

Happy to see this change merged. Could we extend this further?

I'd like to do:

my_network: '{{ (my_project ~ "-netprivate") | default("netpublic") }}'

Currently, I have to:

my_network: '{{ (my_project is defined) | ternary(my_project ~ "-netprivate", "netpublic") }}'

Would it be possible to override the concatenation operator in the same way?

[agaffney]

Doing something similar for the concatenation operator would be much more involved, and probably not worth the effort. You can use the python-style ternary syntax for that, instead.

my_network: '{{ (my_project ~ "-netprivate") if my_project is defined else "netpublic" }}'

[Kassec]

Hi,

Thanks for this PR. I backported it to 2.7 and it saved my life ;)

One thing I'm wondering about: is it normal this new code doesn't handle accessing data with bracket notation ?

- hosts: all

  tasks:
  - name: Check that nested undefined values return Undefined
    vars:
      dict_var:
        bar: {}
      list_var:
      - foo: {}

    assert:
      that:
      - dict_var is defined
      - dict_var.bar is defined
      - dict_var.bar.baz is not defined
      - dict_var.bar.baz | default('DEFAULT') == 'DEFAULT'
      - dict_var.bar.baz.abc is not defined
      - dict_var.bar.baz.abc | default('DEFAULT') == 'DEFAULT'
      - dict_var.bar.baz['abc'] | default('DEFAULT') == 'DEFAULT'
      - dict_var.baz is not defined
      - dict_var.baz.abc is not defined
      - dict_var.baz.abc | default('DEFAULT') == 'DEFAULT'
      - list_var.0 is defined
      - list_var.1 is not defined
      - list_var.0.foo is defined
      - list_var.0.foo.bar is not defined
      - list_var.0.foo.bar | default('DEFAULT') == 'DEFAULT'
      - list_var.1.foo is not defined
      - list_var.1.foo | default('DEFAULT') == 'DEFAULT'

FAILED! => {"msg": "The conditional check 'dict_var.bar.baz['abc'] | default('DEFAULT') == 'DEFAULT'' failed. The error was: error while evaluating conditional (dict_var.bar.baz['abc'] | default('DEFAULT') == 'DEFAULT'): 'dict object' has no attribute 'baz'"}

[agaffney]

All this PR does is replace the class that Jinja returns when it detects an undefined value. It does not touch/change the logic for determining what is undefined or how that is handled.