Initial situation
I fetch the current weekday in my Controller
$dayname = date('l');
For translation I have one dedicated translation file only for the weekdays (weekdays.de.yml)
Monday: Montag
Tuesday: Dienstag
# ...
Now I pass the PHP variable $dayname to my twig file, so that I could call it there with using the trans filter.
{% trans_default_domain 'weekdays' %}
{{ dayname|trans }}
Easy going, works fine.
Objective target
To keep my translations folder tidied up, I want to migrate those weekdays.de.yml into one large single translation file, where I not just organize the weekdays, but all translation elements, e.g. trans.en.yml, trans.de.yml and trans.fr.yml.
# trans.en.yml
# ...
weekdays:
monday: Monday
tuesday: Tuesday
# ...
# trans.de.yml
# ...
weekdays:
monday: Montag
tuesday: Dienstag
# ...
I now could call the appropriate weekday in my twig file like this, e.g. for Monday:
{% trans_default_domain 'trans' %}
{{ weekdays.monday|trans }}
But how can I pass the $dayname variable to the twig file and chose the weekday from my according translation file?
{{ ('weekdays.'~ dayname )|trans }} should do it
Related
In one of my airflow task, I want to pass the current Month current hour and last hour(in UTC) as a variable.
I know macros are there, but the airflow is running with IST timestamp, how can I get the variable data in UTC? any sample code?
execution_date is Pendulum object so you can use in_tz()
{{ execution_date.in_tz('UTC') }}
you can then format the pattern and extract the str as you need.
For example to get the month:
op = BashOperator(
task_id="example",
bash_command="echo the month extracted from {{ execution_date.in_tz('UTC') }}" \
" is {{ execution_date.in_tz('UTC').strftime('%m') }}"
)
I am trying to write an if statement based on a nested grain. I have tried this statement in multiple different ways:
System Services Needed:
module.run:
- name: service.systemctl_reload
- onchanges:
- file: /lib/systemd/system/salt-minion.service
{% if salt['grains.get']('Project:DeviceTypeID') == '2' %}
- file: /etc/rc.local
- file: /opt/interfaces_init.sh
{% endif %}
Returns:
Rendering SLS 'Development:System' failed: Jinja variable 'dict object' has no attribute 'Project:DeviceTypeID'
System Services Needed:
module.run:
- name: service.systemctl_reload
- onchanges:
- file: /lib/systemd/system/salt-minion.service
{% if grains['Project']['DeviceTypeID'] == '2' %}
- file: /etc/rc.local
- file: /opt/interfaces_init.sh
{% endif %}
System Services Needed:
module.run:
- name: service.systemctl_reload
- onchanges:
- file: /lib/systemd/system/salt-minion.service
{% if grains['Project:DeviceTypeID'] == '2' %}
- file: /etc/rc.local
- file: /opt/interfaces_init.sh
{% endif %}
As you can tell from the example their are multiple device type IDs. In this example DeviceTypeID = 2 I need to worry about rc.local and a shell script. I can not seem to get this work for the life of me. I know the grain exists as I can run the following:
sudo salt 'Dev-Box' grains.get Project
and I will get:
Dev-Box:
DeviceTypeID:
1
IsActive:
True
SoftwareEnvironmentName:
Production
SoftwareVersion:
Foo
This is either a bug or I am missing something (significantly more likely I am missing something). Any help would be much appreciated.
Edit 1:
Added ['grains.get']('Project:DeviceTypeID') example
in salt grains.get return a dictionary in the following format:
{'minion-id': value}
I believe if you change your code into something like bellow, it should works.
{% if salt['grains.get']('Project:DeviceTypeID')[minion-id] == '2' %}
If you can't do:
salt 'Dev-Box' grains.get 'Project:DeviceTypeID'
Then you don't actually have the proper grain set.
Try the following:
salt 'Dev-Box' grains.setval Project '{"DeviceTypeID": 2, "IsActive": True, "SoftwareEnvironmentName": "Production", "SoftwareVersion": "Foo"}'
Then the following state:
Do the {{ salt['grains.get']('Project:DeviceTypeID') }} things:
test.succeed_with_changes:
- some: thing
You should get:
ID: Do the 2 things
Function: test.succeed_with_changes
Result: True
Comment: Success!
Started: 17:10:42.739240
Duration: 0.491 ms
Changes:
----------
testing:
----------
new:
Something pretended to change
old:
Unchanged
Given what you wrote elsewhere
salt Dev-Box grains.setval BETTI "{'DeviceTypeID': 2, 'IsActive': True SoftwareEnvironmentName': 'Production', 'SoftwareVersion': 'Foo'}"
Your problem is that you have ' and " confused.
Wrapping the value with " makes it a string. Wrapping it with ' and providing valid JSON makes it a dictionary value.
I'm using SaltStack, and I'm trying to re-use the values of a nested dictionary from one Pillar config in another one. Here's a simple example of what I'm trying to do:
Say I have pillar/app/common.sls which has the following items:
app:
lookup:
custom1: 'change the default'
custom2: 'change the default'
service1:
value1: 'foo'
value2: 'bar'
list1:
- apple
- banana
value3: 'xen'
What I'm aiming for is to have a new service (and the YAML key would be service2) on the same machine, but set up in such a way so that I'm not writing values twice (keep it DRY!). I would also like to override the value of one of the parameters. Essentially, I'm trying to extend one pillar into another.
The end result would be:
app:
lookup:
custom1: 'change the default'
custom2: 'change the default'
service1:
value1: 'foo'
value2: 'bar'
list1:
- apple
- banana
value3: 'xen'
service2:
value1: 'foo'
value2: 'bar'
list1:
- apple
- banana
value3: 'future'
I've tried the following with a pillar/app/someserver.sls:
{% import_yaml "app/common.sls" as common %}
app:
service2:
{{ common.app.service1 }}
value3: 'future'
What I've found is {{ common.app.service1 }} successfully renders, but it doesn't like the additional value3: 'future', which is my attempt to override value3 which comes from common.sls.
I'm using Salt 2016.11.4 on Ubuntu Xenial 16.04.2. Any ideas would be helpful. Thank you!
Since your common.app.service1 variable is nothing more than a common Python dict, you should be able to modify it using update. After that, you can use Jinja's yaml filter to render it into the new pillar:
{% import_yaml "app/common.sls" as common %}
{% set service2 = common.app.service1.copy() %}
{% do service2.update({value3: 'future'}) %}
app:
service2: {{ service2 | yaml }}
I am trying to pull results from a sqlite3 database (set up as an external salt pillar) and use jinja templating to set grains data.
Here is the relevant section of my salt master file:
sqlite3:
database: '/var/lib/salt/stations.db'
timeout: 5.0
ext_pillar:
- sqlite3:
fromdb:
query: 'SELECT * FROM table;'
And here is the relevant part of the init.sls file I am using to create the grains file:
{% set station_id = salt['grains.filter_by']({
{% for row in query_result %}
{% hostname = station_id %}
}, default="UNKNOWN", grain="host") %}
I confirmed that the external pillar produces results by running
salt '*' sqlite3.fetch /var/lib/salt/stations.db 'SELECT * FROM test;'
But I can't figure out how to get results into the jinja file.
I want something like
'SELECT * FROM table WHERE hostname=station_id LIMIT 1;'
and use the result to set the grain environmental variable called 'hostname'.
But am not sure how to get there from here.
Any help is greatly appreciated.
Thanks to the good folks in Saltstack IRC this problem is solved.
Master:
- sqlite3:
station_map:
query: 'SELECT hostname, id
FROM stations
WHERE hostname like ?'
init.sls:
{% set station_id = salt['grains.filter_by']({
{% for row in station_map %}
{{ hostname }} : {{ station_id }}
}, default="UNKNOWN", grain="host") %}
I want to get nodegroup of the minion in the jinjia template or pillar.How can I do it?
e.g. /path/jinjia_template_for_nginx.conf
{% if nodegroup == 'web' %}//nodegroup == get the minion's group
param_xxx 1;
{% else %}
param_xxx 2;
{% endif %}
AFAIK there is no way to get the node group of the current minion via a grain or a pillar directly. You can choose to export your master's configuration to you minion using pillar_opts = True in your master configuration, but any salt-call pillar.get master:nodegroups:web will get you an unexpanded list of hosts that is if no use here.
I suggest you create a pillar for this that maches on the group ...
# pillar top.sls
base:
web:
- match: nodegroup
- webserver
Then set a value of your choice ...
# webserver.sls
mygroup: web
And then use it in the template ...
# nginx.conf
{% if salt['pillar.get']('mygroup', 'unknown') == 'web' %}
param_xxx 1;
{% else %}
param_xxx 2;
{% endif %}
I hope this helps.
Looking at the functionality of nodegroups, pillars and compound matchers you could consider configuring only pillar information and either skip nodegroups, or use a compound matcher using pillar data to define your nodegroups.