Docs: Define general code rules #121

New issue

Open

opened 2025-03-23 22:18:15 +01:00 by saibotk · 1 comment

saibotk commented

2025-03-23 22:18:15 +01:00

Owner

As identified in #97, we should define some standards.

This can include, but is not limited to:

Code Style
Default Install paths
Default variable verbosity (how much stuff should be configurable)
Hard-coding of variables that are necessary to run the service (e.g. postgres hostnames etc. not exposed as variables or overridable)

As identified in #97, we should define some standards. This can include, but is not limited to: - Code Style - Default Install paths - Default variable verbosity (how much stuff should be configurable) - Hard-coding of variables that are necessary to run the service (e.g. postgres hostnames etc. not exposed as variables or overridable)

histalek commented

2025-03-29 14:40:38 +01:00

Owner

Additionally:

prevent secrets from being logged/displayed; through no_log=true [1] on specific tasks or better !unsafe [2] on those vars
set default variables

regarding the last point i'd like to move away from 'example' vars and only set variables that would actually be usable.
This would lead to playbooks failing (this already happens) with unset variable errors. Which is IMO better than currently where playbooks/roles might run through but leave an unusable state.
If we would like to we could also make use of the argument_spec [3] and validate through that. But that might be quite a lot of work for a not so big upside.

[1] https://docs.ansible.com/ansible/latest/reference_appendices/logging.html#protecting-sensitive-data-with-no-log

[2] https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_advanced_syntax.html#unsafe-or-raw-strings

[3] https://docs.ansible.com/ansible/latest/dev_guide/developing_program_flow_modules.html#argument-spec

Additionally: * prevent secrets from being logged/displayed; through `no_log=true` [1] on specific tasks or better `!unsafe` [2] on those vars * set default variables regarding the last point i'd like to move away from 'example' vars and only set variables that would actually be usable. This would lead to playbooks failing (this already happens) with unset variable errors. Which is IMO better than currently where playbooks/roles might run through but leave an unusable state. If we would like to we could also make use of the argument_spec [3] and validate through that. But that might be quite a lot of work for a not so big upside. [1] https://docs.ansible.com/ansible/latest/reference_appendices/logging.html#protecting-sensitive-data-with-no-log [2] https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_advanced_syntax.html#unsafe-or-raw-strings [3] https://docs.ansible.com/ansible/latest/dev_guide/developing_program_flow_modules.html#argument-spec

👍 1

No labels

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: SipsOfCode/infrastructure#121

No description provided.

Rows
Columns