[HN Gopher] Interesting Uses of Ansible's ternary filter
___________________________________________________________________
Interesting Uses of Ansible's ternary filter
Author : zufallsheld
Score : 40 points
Date : 2024-02-22 10:16 UTC (12 hours ago)
(HTM) web link (www.zufallsheld.de)
(TXT) w3m dump (www.zufallsheld.de)
| raziel2p wrote:
| Why would you use this instead of e.g. {{ "--
| quiet" if ansible_verbosity == 0 }}
|
| https://jinja.palletsprojects.com/en/3.1.x/templates/#if-exp...
| switch007 wrote:
| I was wondering the same thing. I tested it and it works fine.
| It defaults to an empty string if there is no "else".
| zufallsheld wrote:
| Probably because the author of this piece of code was not aware
| of it. :)
|
| Thanks, I updated the blog-post.
| cpburns2009 wrote:
| I'm genuinely surprised you can use if-else expressions in
| Jinja. Jinja uses such neutered expressions I would have looked
| for an equivalent ternary/iff filter.
| mdaniel wrote:
| They support for-if from python, too: https://jinja.palletspr
| ojects.com/en/3.1.x/templates/#loop-f... but I haven't tried
| the "recursive" keyword to know if ansible supports that. I
| say "ansible supports that" because they don't just drop
| jinja2 into ansible and call it a draw, they have a bunch of
| custom execution integrations: https://github.com/ansible/ans
| ible/blob/v2.16.3/lib/ansible/...
| kunley wrote:
| Cool. Ansible is still going to be around for some time.
|
| Also reminds me again that yaml should have never been born. Look
| how unnatural this "language" is in this article's examples
| xienze wrote:
| Most of that is the embedded templating/scripting system (the
| stuff between {{}}), not YAML itself.
| zufallsheld wrote:
| Well, that's Jinja. And arguably not a bad tool, but not the
| best for the use-case of config-management.
| kunley wrote:
| Yeah, I just have this sentiment wishing that Ansible's
| author used own-crafted format. HashiCorp used their own
| and suddenly in this case no one says "yaml should be
| everywhere because it's everywhere already".
|
| In a similar mood, I wished Kubernetes was staying every
| from yaml. Even mentioned HCL would be better (although
| it's not perfect)
| kunley wrote:
| Yes but the task names and parameters try to mimic natural
| language, like assert: that:, so you're supposed to read it
| as a whole, and it quickly turns into an abomination, with
| one syntax (yaml) for the structure and another (jinja) for
| values and conditions
| avgcorrection wrote:
| Yeah. I don't understand why _we_ keep submitting ourselves to
| this way of working.
| linsomniac wrote:
| IMHO, the issue is that Ansible uses YAML to do "programming
| language" sorts of things, which is why it feels so unnatural.
|
| I tried an experiment last year: What if Ansible had Python
| rather than YAML syntax.
| https://github.com/linsomniac/uplaybook?tab=readme-ov-file#s...
|
| The downside is that having full Python available makes it
| really easy to make your playbooks non-idempotent, which
| Ansible gate-keeps behind Ansible modules. Also someone raised
| a concern that full Python (rather than a more limited safe
| dialect like Starlark) would make it harder to trust third-
| party playbooks. But considering uPlaybook's use case (ansible-
| like system configuration) it feels like even with a restricted
| dialect it is going to have plenty of opportunity for nefarious
| purposes.
|
| I've put out uPlaybook for some limited review among my
| friends, and I've gotten some excitement about it. It doesn't
| have fleet management and remote running though, which is the
| big negative feedback I've gotten. I'm interested in thoughts
| on it though.
| kimbernator wrote:
| I really wish Ansible would have chosen to use python instead of
| YAML (since that's what it ends up being anyways). Shoehorning
| actual programming logic into YAML files is just awful; Working
| with Ansible as a software engineer is without a doubt the worst
| work I've done in my professional career. Every otherwise simple
| logic structure in any programming language like loops, variable
| declaration, or conditional statements take 5x as much space and
| are very difficult to understand immediately.
|
| My first love in this space was Chef, and honestly it remains my
| favorite in config management because you can write things in it
| that look very non-programmy, but you're still just writing in
| pure ruby. Obviously Ansible has the advantage being agentless,
| but I just cannot stand how popular it is.
| SteveNuts wrote:
| Ansible is a nice tradeoff to allow sysadmins with no
| programming experience to work with it, and someday hopefully
| graduate to something else. For that, I think it's a net-
| positive.
|
| But yes, trying to work with even mildly complex data
| structures in Ansible is a nightmare compared to raw Python.
| zufallsheld wrote:
| As a counter anecdote I can tell you that all of the ops-people
| I worked with, they gladly switched from Puppet and Chef to
| Ansible, specifically because it was less programming and more
| shell-like.
|
| Not that this is good or bad, but I think that's why Ansible
| took off with the traditional operations-teams.
| jauntywundrkind wrote:
| More shell like, and more normative. There's a given form &
| shape in Ansible; playbooks resemble each other.
|
| You don't get that with programming languages. People do all
| kinds of shit with programming languages. There's tons of
| good ways to tackle a problem. And exponentially many more
| _bad_ ways to tackle a problem.
|
| Having a given repeated form makes interpreting &
| understanding Ansible far easier than the alternatives.
| syslog wrote:
| If you try to use a hammer like a screwdriver, you're going to
| be frustrated.
| mikeocool wrote:
| When I was first using chef -- and didn't quite get the
| paradigm -- it was really easy to fallback to a lot of native
| ruby. i.e. "I dont want to run these resources in certain
| contexts, let me just wrap them in an if statement." Which
| ended up creating a bit of a mess over time, and broke some of
| chef's functionality.
|
| By using yaml ansible basically forces you to be purely
| declarative, which I found to be a boon, especially once other
| engineers who similarly didn't initially get the declarative
| paradigm started on working in the codebase.
| xorcist wrote:
| I see you haven't worked with Istio, yet.
|
| Kidding aside, it is somewhat amusing to see the same
| discussion as when chef happened repeat itself.
|
| Ansible clearly had to take a lot of liberties with the yaml
| format to make it work in practice. The amount of yaml in yaml
| you have to write is surprising. I cannot wait for the cycle to
| repeat itself.
| mdaniel wrote:
| > Ansible clearly had to take a lot of liberties with the
| yaml format to make it work in practice
|
| and yet, completely facepalmed by invoking Jinja2 with its
| default begin and end characters that are meaningful to yaml,
| thus ensuring billions of person-years of SO questions due to
| having to quote, sometimes multiple ways, every jinja2
| invocation
|
| Contrast that to GitHub Actions which uses ${{ }} for its
| parameterization and thus no quoting required, in contrast to
| - debug: msg: '{{ "what kind of lack of forethought
| was this nonsense" }}'
| dig1 wrote:
| I think this is more a personal preference rather than
| something practical. As a counter-example, I've implemented
| Ansible-like syntax as a configuration for a couple of
| unrelated projects, and people like it because it is similar to
| Ansible, which is used for infrastructure management. I doubt
| I'd do that by writing a parser for Python-like configuration
| language.
|
| Also, don't forget that yaml is way easier to pick up by non-
| python developers and people unfamiliar with programming.
| bityard wrote:
| Haven't used it in anger yet, but I have high hopes for
| PyInfra: https://github.com/pyinfra-dev/pyinfra
| pton_xd wrote:
| Ansible is great as long as you keep Jinja use to a minimum.
| Basic variable substitution handles 90% of what you need. Ternary
| filter... doesn't qualify.
|
| Everything else should just be handled by a python script to
| orchestrate the playbooks.
| IncreasePosts wrote:
| Never thought I'd see a blog post describing an if statement.
| zufallsheld wrote:
| You're welcome. :)
| Szpadel wrote:
| I use it to conditionally add elements to array or dict in
| group_vars, real life example:
|
| aws_tags_pio: RoleImage: "pio"
|
| aws_tags_role_app_tpl: [ { Role: "app" }, "{{
| (mageops_pio_worker_enable and not
| mageops_pio_worker_dedicated_asg) | ternary(aws_tags_pio, {}) }}"
| ]
|
| aws_tags_role_app: "{{ aws_tags_role_app_tpl | combine }}"
|
| https://github.com/mageops/ansible-infrastructure/blob/5dcc3...
|
| for array you use flatten eg
|
| aws_security_group_persistant_rules_tpl: [ "{{
| mageops_ssh_proxy_persistant |
| ternary(aws_security_group_persistant_rules_ssh_proxy, []) }}",
| "{{ mageops_tinyproxy_persistant_enabled |
| ternary(aws_security_group_persistent_rules_tinyproxy, []) }}" ]
|
| aws_security_group_persistant_rules: "{{
| aws_security_group_persistant_rules_tpl | flatten }}"
|
| this pattern really helped to clean up conditionals that normally
| had to be done in tasks
___________________________________________________________________
(page generated 2024-02-22 23:02 UTC)