Conversation
363588f to
1fee3d5
Compare
|
|
||
| - name: Clean cache | ||
| apt: | ||
| autoclean: yes |
There was a problem hiding this comment.
Do you think we should be adding in here also the creation of the accounts, like what dom0 is doing?
There was a problem hiding this comment.
The bootstrap is quite different from dom0, maybe we can deploy new nodes with these new roles over the next months before starting to backport stuff (due to the risk of breaking live nodes).
There was a problem hiding this comment.
So currently to deploy this, you would still have to run the dom0 bootstrap playbook on it?
There was a problem hiding this comment.
Updated to create users
| - /dev/xvde1 | ||
| - /dev/xvdf1 | ||
| - /dev/xvdg1 | ||
| - /dev/xvdh1 |
There was a problem hiding this comment.
Maybe, since these are about the specific disk setup of the particular ams-pg host, these should go outside of the postgresql11 role?
There was a problem hiding this comment.
Active and standby DB hosts are pretty critical. I think it's safer to dedicate a role for a specific host (instead of having variables and conditionals that can cause unexpected changes on a host A while we are changing host B).
There was a problem hiding this comment.
Makes sense, perhaps then the role name should contain the active/standby role in it?
hellais
left a comment
There was a problem hiding this comment.
Did another pass at reviewing. Let me know with inline comments if there are specific areas I should be focusing on.
|
|
||
| - name: configure netdata nginx | ||
| blockinfile: | ||
| path: /etc/netdata/python.d/chrony.conf |
There was a problem hiding this comment.
Is this a typo, or is it normal that it’s writing to the same file?
| name: nftables.service | ||
| state: reloaded | ||
|
|
||
| - name: configure netdata.service |
There was a problem hiding this comment.
Is there a reason to use blockinfile instead of file or template?
There was a problem hiding this comment.
Better readability: we can scan through the task file and see what is being done.
| @@ -0,0 +1,4 @@ | |||
| --- | |||
| dependencies: | |||
There was a problem hiding this comment.
So the key here is that the role itself will specify the dependencies for other roles, correct?
I think this a reasonable approach, though we should probably document this architecture/pattern somewhere as it might not be immediately obvious this is how roles should be written from now on.
| static_configs: | ||
| - targets: | ||
| {% for target in bbjob.targets %} | ||
| {% for target in (bbjob.targets|sort) %} |
There was a problem hiding this comment.
Was the sort added to make the diff more deterministic? I am surprised that ansible did not do it automatically.
There was a problem hiding this comment.
Yes the first, no to the latter: the diff was random every time
| format: [prometheus] | ||
| static_configs: | ||
| - targets: | ||
| - ams-pg.ooni.nu:9187 |
There was a problem hiding this comment.
What is the difference between these two netadata endpoints and the ones that have_netdata?
| @@ -0,0 +1,8 @@ | |||
| --- | |||
| dependencies: | |||
| - role: track_etc_directory | |||
There was a problem hiding this comment.
Maybe this is a bit too much indirection? Can we put the content of this in the role directly for the time being and abstract it when N > 1 roles need to depend on this and not the base one?
There was a problem hiding this comment.
base-buster and letsencrypt already both depend on it (and don't depend on each other)
| @@ -0,0 +1,101 @@ | |||
|
|
|||
| # Managed by ansible | |||
| # roles/nginx-buster/templates/nginx.conf | |||
There was a problem hiding this comment.
Where is this role being included?
1de5815 to
c010bd4
Compare
5ad8345 to
dda26af
Compare
No description provided.