Using terraform, I'd like to see if there's a way — with the template rendering system — to define a template_file in a terraform module (base template) and then "extend" or "append" to the rendering in the instantiation rather than replaced.
I can currently define the template_file in either location, but would like to know if I can build upon the module's template on a per-instance basis. The specific use case is for userdata on AWS EC2s which vary slightly from instance type to instance type.
Thank you,
Neurax
This is what I ended up finding out.
In the module. Define an a template_file for the base template. Then define an output (for example named "module_template") whose value is equal to the rendered version of the template_file.
Then in the instantiation, define another template_file with a var equal to something like mod_temp = "${module.module_name.module_template}", and then in the template_file, reference that variable where necessary with ${mod_temp}.
I was thinking about trying to escape values in the "super template" so that maybe they would get interpolated during the "sub template's" rendering. Initial tests have not been successful.
Related
onvif python will create base variables from WSDL but not the optional elements. How do I add the optional variables to the existing definition?
as in a = create(sometype)
This defines the elements a.b and a.c.
I need to add elements a.c.d, a.c.e.g and a.c.e.h.
The short answer: It depends on what the existing variable is.
The longer answer: Since the existing variable is defined by a third party library with little to no visibility, run the code under a debugger that will tell you what the existing variable is, e.g, list, dict, etc. From that information look in the python documentation if you are not familiar with that type of variable.
How can I achieve something like this in Hiera?
service::enabled: true
plugin:
sensu:
ensure: (if service::enabled: 'present' else 'absent')
I know I can do this with puppet but would like to avoid that.
If you really, really (see below why you don't want to do this) want to have conditional logic in your data, then you could use my tahu::ppyaml() hiera backend which allows you to have puppet logic embedded in the yaml data, or write your own specific backend function. The tahu module requires Puppet 6. For versions of puppet before Hiera 5 you need to write a hiera 3 backend to achieve something similar. With Hiera 5 a backend function is very simple and can even be written in the puppet language.
You can find the tahu::ppayaml function here:
https://github.com/hlindberg/tahu/blob/master/lib/puppet/functions/tahu/ppyaml_key.rb
Your data would then look like this:
service::enabled: true
plugin:
sensu:
ensure: "if $service::enabled { 'present'} else {'absent'}"
Since the ppyaml backend treats every string as puppet language you need to quote all literal strings in the data file read by ppyaml; for example "'foo'" or '"foo"'.
You can however break out the key with a conditional into a separate file and use and alias in your main data file. Like this:
service::enabled: true
plugin:
sensu:
ensure: '%{alias("sensu::ensure")}'
And then, either using the tahu::ppyaml to bind only dynamic keys:
sensu::ensure: if $service::enabled { 'present'} else {'absent'}"
and adding that to your hiera.yaml referencing tahu::ppyaml as a backend.
It would work the same way if you write your own backend.
If any of this is recommended is a different question as it is questionable to have conditional logic in the data that depends on a variable being set or not in a manifest as you will get one value if you do the lookup before the inclusion of sensu and a different value after - and you are probably looking up the hash for the very purpose of declaring sensu.
Unfortunately, Hiera doesn't have expressions that can do anything as sophisticated as conditional logic.
There are some aliasing and lookup functions, so you may be able to pass the value service::enabled through unmodified, but that is it. The functions in Hiera are documented at https://puppet.com/docs/puppet/latest/hiera_merging.html.
I'm trying to use the keys expression in Terraform to grab a list of keys (from a map variable) and assign it to a local variable. Here is the code snippet:
locals {
project_name_list = keys(${var.project_map})
}
However, I'm getting the following error:
Unknown token: 29:22 IDENT keys
Am I missing something here. Nowhere can I find an example of this expression. As bad as it is, even the official documentation does not help -https://www.terraform.io/docs/configuration/functions/keys.html
HashiCorp has really done a bad job of elaborating the nuances of Terraform for beginners on their website.
Terraform functions need to be wrapped in expression syntax to show that it's not a literal value: "${}"
So try this: project_name_list = "${keys(var.project_map)}"
The example in the documentation is written as though being run from the terraform command line, which already assumes the command is a HCL expression and doesn't require that syntax.
UPDATE
I said above that the expression syntax is to show that it's not a literal value. It's probably more accurate to speak of it as expression syntax vs. configuration syntax. Configuration syntax is the first level of interpolation, which forms the basic structure of your terraform file with resource blocks, data blocks, etc. The second interpolation level is expression syntax which is used to generate values used by your configuration.
Thinking of it in these terms makes better sense of the error message, Unknown token, because terraform is attempting to read it as a configuration key word.
I had compared it to a literal value because it's in the same position as where a literal value would be.
Terraform allows for easy interpolation of resource attributes when they are created with count = N like :
${resource.name.*.attr[X]}
What I would like is to access the attribute for all resources of this type regardless of it's name. Something like
${resource.*.*.attr[X]}
would do, but terraform does not seem to support this kind of notation. Any idea if/how this can be done ?
I am using a simple looping plugin so that my template looks like this:
{exp:loop_plus start="1" end="4" increment="1"}
<h3>{slide_{index}_title}</h3>
{/exp:loop_plus}
However, I am ending up with the following output:
<h3>{slide_1_title}</h3>
<h3>{slide_2_title}</h3>
<h3>{slide_3_title}</h3>
<h3>{slide_4_title}</h3>
Is there any way I can have dynamic variable names like this? I am not looking for alternative methods for building a slider, I simply would like to know if the dynamic variable names like this is possible. Thanks!
I'm assuming that Loop Plus (http://devot-ee.com/add-ons/loop-plus) sets the {index} part, so the question is what is defining {slide_1_title}...?
Assuming you have an entry field or variable with this defined, what you have is correct, but if it's not working, it means there's a parsing order issue.
Let's assume the code you supplied is wrapped in a {exp:channel:entries} tag pair, what happens is EE will try to parse the variable first, so will see: {slide_{index}_title} which doesn't exist. The {exp:loop_plus} add-on will then parse it, converting it to {slide_1_title} (but to late as channel:entries has already tried to parse it), which is what is finally output to the template.
So what you want to ensure is that EE parses {exp:loop_plus} before {exp:channel:entries}, do this using parse="inward" tag:
{exp:loop_plus start="1" end="4" increment="1" parse="inward"}
<h3>{slide_{index}_title}</h3>
{/exp:loop_plus}
This is a global EE parameter that EE uses to control parse order - you won't find it documented under the specific add-on. By adding the parameter, it means this child tag will get parsed before it's parent.
One way you could do it is to declare a preload_replace variable in your template and use it in your custom field name.
So something like:
{preload_replace:my_var_prefix="whatever"}
And then in your loop, you could then use:
{slide_{my_var_prefix}_title}