karel/salt-gitea-formula
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
jeanluc
2022-04-20 22:37:39 +02:00
commit e7d7cf9c59
117 changed files with 8981 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/Makefile Normal file
View File

@@ -0,0 +1,20 @@
# Minimal makefile for Sphinx documentation
#
# You can set these variables from the command line, and also
# from the environment for the first two.
SPHINXOPTS ?=
SPHINXBUILD ?= sphinx-build
SOURCEDIR = .
BUILDDIR = _build
# Put it first so that "make" without argument is like "make help".
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
.PHONY: help Makefile
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

188
docs/README.rst Normal file
View File

@@ -0,0 +1,188 @@
.. _readme:
Gitea Formula
=============
|img_sr| |img_pc|
.. |img_sr| image:: https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg
:alt: Semantic Release
:scale: 100%
:target: https://github.com/semantic-release/semantic-release
.. |img_pc| image:: https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white
:alt: pre-commit
:scale: 100%
:target: https://github.com/pre-commit/pre-commit
Manage Gitea with Salt.
.. contents:: **Table of Contents**
:depth: 1
General notes
-------------
See the full `SaltStack Formulas installation and usage instructions
<https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html>`_.
If you are interested in writing or contributing to formulas, please pay attention to the `Writing Formula Section
<https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html#writing-formulas>`_.
If you want to use this formula, please pay attention to the ``FORMULA`` file and/or ``git tag``,
which contains the currently released version. This formula is versioned according to `Semantic Versioning <http://semver.org/>`_.
See `Formula Versioning Section <https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html#versioning>`_ for more details.
If you need (non-default) configuration, please refer to:
- `how to configure the formula with map.jinja <map.jinja.rst>`_
- the ``pillar.example`` file
- the `Special notes`_ section
Special notes
-------------
* This installs from the `official binary source <https://dl.gitea.io/gitea/>`_.
* The formula is currently Linux/systemd-centric. It should be relatively easy to provide the correct parameters and service file for other platforms though.
* Since the formula skips the web installer, you will need to provide at least the database configuration.
* You can optionally specify the secrets, but they can be autogenerated by Salt as well. In that case, they will be saved in a grain value.
* Secrets and database config will be written to the global config file, the rest into ``custom/conf/app.ini``.
* All the paths are modifiable, find them in ``lookup:paths``. You should not need to set the corresponding values in your config, they are added automatically.
* If Gitea requires mounts for some of the paths, you can specify them in ``service:requires_mount`` as a list.
* If Gitea requires a local service unit (e.g. database server), specify it/them in ``service:wants`` as a list.
Configuration
-------------
An example pillar is provided, please see `pillar.example`. Note that you do not need to specify everything by pillar. Often, it's much easier and less resource-heavy to use the ``parameters/<grain>/<value>.yaml`` files for non-sensitive settings. The underlying logic is explained in `map.jinja`.
Available states
----------------
.. contents::
:local:
``gitea``
^^^^^^^^^
*Meta-state (This is a state that includes other states)*.
This installs the gitea package,
manages the gitea configuration file and then
starts the associated gitea service.
``gitea.package``
^^^^^^^^^^^^^^^^^
This state will install the gitea package only.
``gitea.config``
^^^^^^^^^^^^^^^^
This state will configure the gitea service and has a dependency on ``gitea.install``
via include list.
``gitea.service``
^^^^^^^^^^^^^^^^^
This state will start the gitea service and has a dependency on ``gitea.config``
via include list.
``gitea.clean``
^^^^^^^^^^^^^^^
*Meta-state (This is a state that includes other states)*.
This state will undo everything performed in the ``gitea`` meta-state in reverse order, i.e.
stops the service,
removes the configuration file and
then uninstalls the package. Some paths are left to avoid accidental data loss (namely ``GITEA_WORKDIR``, ``APP_DATA_PATH`` and the gitea user home).
``gitea.service.clean``
^^^^^^^^^^^^^^^^^^^^^^^
This state will stop the gitea service and disable it at boot time.
``gitea.config.clean``
^^^^^^^^^^^^^^^^^^^^^^
This state will remove the configuration of the gitea service and has a
dependency on ``gitea.service.clean`` via include list.
``gitea.package.clean``
^^^^^^^^^^^^^^^^^^^^^^^
This state will remove the gitea package and has a depency on
``gitea.config.clean`` via include list.
Contributing to this repo
-------------------------
Commit messages
^^^^^^^^^^^^^^^
**Commit message formatting is significant!**
Please see `How to contribute <https://github.com/saltstack-formulas/.github/blob/master/CONTRIBUTING.rst>`_ for more details.
pre-commit
^^^^^^^^^^
`pre-commit <https://pre-commit.com/>`_ is configured for this formula, which you may optionally use to ease the steps involved in submitting your changes.
First install the ``pre-commit`` package manager using the appropriate `method <https://pre-commit.com/#installation>`_, then run ``bin/install-hooks`` and
now ``pre-commit`` will run automatically on each ``git commit``. ::
$ bin/install-hooks
pre-commit installed at .git/hooks/pre-commit
pre-commit installed at .git/hooks/commit-msg
State documentation
~~~~~~~~~~~~~~~~~~~
There is a script that semi-autodocuments available states: ``bin/slsdoc``.
If a ``.sls`` file begins with a Jinja comment, it will dump that into the docs. It can be configured differently depending on the formula. See the script source code for details currently.
This means if you feel a state should be documented, make sure to write a comment explaining it.
Testing
-------
Linux testing is done with ``kitchen-salt``.
Requirements
^^^^^^^^^^^^
* Ruby
* Docker
.. code-block:: bash
$ gem install bundler
$ bundle install
$ bin/kitchen test [platform]
Where ``[platform]`` is the platform name defined in ``kitchen.yml``,
e.g. ``debian-9-2019-2-py3``.
``bin/kitchen converge``
^^^^^^^^^^^^^^^^^^^^^^^^
Creates the docker instance and runs the ``gitea`` main state, ready for testing.
``bin/kitchen verify``
^^^^^^^^^^^^^^^^^^^^^^
Runs the ``inspec`` tests on the actual instance.
``bin/kitchen destroy``
^^^^^^^^^^^^^^^^^^^^^^^
Removes the docker instance.
``bin/kitchen test``
^^^^^^^^^^^^^^^^^^^^
Runs all of the stages above in one go: i.e. ``destroy`` + ``converge`` + ``verify`` + ``destroy``.
``bin/kitchen login``
^^^^^^^^^^^^^^^^^^^^^
Gives you SSH access to the instance for manual testing.

518
docs/TOFS_pattern.rst Normal file
View File

@@ -0,0 +1,518 @@
.. _tofs_pattern:
TOFS: A pattern for using SaltStack
===================================
.. list-table::
:name: tofs-authors
:header-rows: 1
:stub-columns: 1
:widths: 2,2,3,2
* -
- Person
- Contact
- Date
* - Authored by
- Roberto Moreda
- moreda@allenta.com
- 29/12/2014
* - Modified by
- Daniel Dehennin
- daniel.dehennin@baby-gnu.org
- 07/02/2019
* - Modified by
- Imran Iqbal
- https://github.com/myii
- 23/02/2019
All that follows is a proposal based on my experience with `SaltStack <http://www.saltstack.com/>`_. The good thing of a piece of software like this is that you can "bend it" to suit your needs in many possible ways, and this is one of them. All the recommendations and thoughts are given "as it is" with no warranty of any type.
.. contents:: **Table of Contents**
Usage of values in pillar vs templates in ``file_roots``
--------------------------------------------------------
Among other functions, the *master* (or *salt-master*) serves files to the *minions* (or *salt-minions*). The `file_roots <http://docs.saltstack.com/en/latest/ref/file_server/file_roots.html>`_ is the list of directories used in sequence to find a file when a minion requires it: the first match is served to the minion. Those files could be `state files <http://docs.saltstack.com/en/latest/topics/tutorials/starting_states.html>`_ or configuration templates, among others.
Using SaltStack is a simple and effective way to implement configuration management, but even in a `non-multitenant <http://en.wikipedia.org/wiki/Multitenancy>`_ scenario, it is not a good idea to generally access some data (e.g. the database password in our `Zabbix <http://www.zabbix.com/>`_ server configuration file or the private key of our `Nginx <http://nginx.org/en/>`_ TLS certificate).
To avoid this situation we can use the `pillar mechanism <http://docs.saltstack.com/en/latest/topics/pillar/>`_, which is designed to provide controlled access to data from the minions based on some selection rules. As pillar data could be easily integrated in the `Jinja <http://docs.saltstack.com/en/latest/topics/tutorials/pillar.html>`_ templates, it is a good mechanism to store values to be used in the final rendering of state files and templates.
There are a variety of approaches on the usage of pillar and templates as seen in the `saltstack-formulas <https://github.com/saltstack-formulas>`_' repositories. `Some <https://github.com/saltstack-formulas/nginx-formula/pull/18>`_ `developments <https://github.com/saltstack-formulas/php-formula/pull/14>`_ stress the initial purpose of pillar data into a storage for most of the possible variables for a determined system configuration. This, in my opinion, is shifting too much load from the original template files approach. Adding up some `non-trivial Jinja <https://github.com/saltstack-formulas/nginx-formula/blob/f74254c07e188bd448eaf1c5f9c802d78c4c005e/nginx/files/default/nginx.conf>`_ code as essential part of composing the state file definitely makes SaltStack state files (hence formulas) more difficult to read. The extreme of this approach is that we could end up with a new render mechanism, implemented in Jinja, storing everything needed in pillar data to compose configurations. Additionally, we are establishing a strong dependency with the Jinja renderer.
In opposition to the *put the code in file_roots and the data in pillars* approach, there is the *pillar as a store for a set of key-values* approach. A full-blown configuration file abstracted in pillar and jinja is complicated to develop, understand and maintain. I think a better and simpler approach is to keep a configuration file templated using just a basic (non-extensive but extensible) set of pillar values.
On the reusability of SaltStack state files
-------------------------------------------
There is a brilliant initiative of the SaltStack community called `salt-formulas <https://github.com/saltstack-formulas>`_. Their goal is to provide state files, pillar examples and configuration templates ready to be used for provisioning. I am a contributor for two small ones: `zabbix-formula <https://github.com/saltstack-formulas/zabbix-formula>`_ and `varnish-formula <https://github.com/saltstack-formulas/varnish-formula>`_.
The `design guidelines <http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html>`_ for formulas are clear in many aspects and it is a recommended reading for anyone willing to write state files, even non-formulaic ones.
In the next section, I am going to describe my proposal to extend further the reusability of formulas, suggesting some patterns of usage.
The Template Override and Files Switch (TOFS) pattern
-----------------------------------------------------
I understand a formula as a **complete, independent set of SaltStack state and configuration template files sufficient to configure a system**. A system could be something as simple as an NTP server or some other much more complex service that requires many state and configuration template files.
The customization of a formula should be done mainly by providing pillar data used later to render either the state or the configuration template files.
Example: NTP before applying TOFS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Let's work with the NTP example. A basic formula that follows the `design guidelines <http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html>`_ has the following files and directories tree:
.. code-block:: console
/srv/saltstack/salt-formulas/ntp-saltstack-formula/
ntp/
map.jinja
init.sls
conf.sls
files/
default/
etc/
ntp.conf.jinja
In order to use it, let's assume a `masterless configuration <http://docs.saltstack.com/en/latest/topics/tutorials/quickstart.html>`_ and this relevant section of ``/etc/salt/minion``:
.. code-block:: yaml
pillar_roots:
base:
- /srv/saltstack/pillar
file_client: local
file_roots:
base:
- /srv/saltstack/salt
- /srv/saltstack/salt-formulas/ntp-saltstack-formula
.. code-block:: jinja
{#- /srv/saltstack/salt-formulas/ntp-saltstack-formula/ntp/map.jinja #}
{%- set ntp = salt['grains.filter_by']({
'default': {
'pkg': 'ntp',
'service': 'ntp',
'config': '/etc/ntp.conf',
},
}, merge=salt['pillar.get']('ntp:lookup')) %}
In ``init.sls`` we have the minimal states required to have NTP configured. In many cases ``init.sls`` is almost equivalent to an ``apt-get install`` or a ``yum install`` of the package.
.. code-block:: sls
## /srv/saltstack/salt-formulas/ntp-saltstack-formula/ntp/init.sls
{%- from 'ntp/map.jinja' import ntp with context %}
Install NTP:
pkg.installed:
- name: {{ ntp.pkg }}
Enable and start NTP:
service.running:
- name: {{ ntp.service }}
- enabled: True
- require:
- pkg: Install NTP package
In ``conf.sls`` we have the configuration states. In most cases, that is just managing configuration file templates and making them to be watched by the service.
.. code-block:: sls
## /srv/saltstack/salt-formulas/ntp-saltstack-formula/ntp/conf.sls
include:
- ntp
{%- from 'ntp/map.jinja' import ntp with context %}
Configure NTP:
file.managed:
- name: {{ ntp.config }}
- template: jinja
- source: salt://ntp/files/default/etc/ntp.conf.jinja
- watch_in:
- service: Enable and start NTP service
- require:
- pkg: Install NTP package
Under ``files/default``, there is a structure that mimics the one in the minion in order to avoid clashes and confusion on where to put the needed templates. There you can find a mostly standard template for the configuration file.
.. code-block:: jinja
{#- /srv/saltstack/salt-formulas/ntp-saltstack-formula/ntp/files/default/etc/ntp.conf.jinja #}
{#- Managed by saltstack #}
{#- Edit pillars or override this template in saltstack if you need customization #}
{%- set settings = salt['pillar.get']('ntp', {}) %}
{%- set default_servers = ['0.ubuntu.pool.ntp.org',
'1.ubuntu.pool.ntp.org',
'2.ubuntu.pool.ntp.org',
'3.ubuntu.pool.ntp.org'] %}
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
{%- for server in settings.get('servers', default_servers) %}
server {{ server }}
{%- endfor %}
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
With all this, it is easy to install and configure a simple NTP server by just running ``salt-call state.sls ntp.conf``: the package will be installed, the service will be running and the configuration should be correct for most of cases, even without pillar data.
Alternatively, you can define a highstate in ``/srv/saltstack/salt/top.sls`` and run ``salt-call state.highstate``.
.. code-block:: sls
## /srv/saltstack/salt/top.sls
base:
'*':
- ntp.conf
**Customizing the formula just with pillar data**, we have the option to define the NTP servers.
.. code-block:: sls
## /srv/saltstack/pillar/top.sls
base:
'*':
- ntp
.. code-block:: sls
## /srv/saltstack/pillar/ntp.sls
ntp:
servers:
- 0.ch.pool.ntp.org
- 1.ch.pool.ntp.org
- 2.ch.pool.ntp.org
- 3.ch.pool.ntp.org
Template Override
^^^^^^^^^^^^^^^^^
If the customization based on pillar data is not enough, we can override the template by creating a new one in ``/srv/saltstack/salt/ntp/files/default/etc/ntp.conf.jinja``
.. code-block:: jinja
{#- /srv/saltstack/salt/ntp/files/default/etc/ntp.conf.jinja #}
{#- Managed by saltstack #}
{#- Edit pillars or override this template in saltstack if you need customization #}
{#- Some bizarre configurations here #}
{#- ... #}
{%- for server in settings.get('servers', default_servers) %}
server {{ server }}
{%- endfor %}
This way we are locally **overriding the template files** offered by the formula in order to make a more complex adaptation. Of course, this could be applied as well to any of the files, including the state files.
Files Switch
^^^^^^^^^^^^
To bring some order into the set of template files included in a formula, as we commented, we suggest having a similar structure to a normal final file system under ``files/default``.
We can make different templates coexist for different minions, classified by any `grain <http://docs.saltstack.com/en/latest/topics/targeting/grains.html>`_ value, by simply creating new directories under ``files``. This mechanism is based on **using values of some grains as a switch for the directories under** ``files/``.
If we decide that we want ``os_family`` as switch, then we could provide the formula template variants for both the ``RedHat`` and ``Debian`` families.
.. code-block:: console
/srv/saltstack/salt-formulas/ntp-saltstack-formula/ntp/files/
default/
etc/
ntp.conf.jinja
RedHat/
etc/
ntp.conf.jinja
Debian/
etc/
ntp.conf.jinja
To make this work we need a ``conf.sls`` state file that takes a list of possible files as the configuration template.
.. code-block:: sls
## /srv/saltstack/salt-formulas/ntp-saltstack-formula/ntp/conf.sls
include:
- ntp
{%- from 'ntp/map.jinja' import ntp with context %}
Configure NTP:
file.managed:
- name: {{ ntp.config }}
- template: jinja
- source:
- salt://ntp/files/{{ grains.get('os_family', 'default') }}/etc/ntp.conf.jinja
- salt://ntp/files/default/etc/ntp.conf.jinja
- watch_in:
- service: Enable and start NTP service
- require:
- pkg: Install NTP package
If we want to cover the possibility of a special template for a minion identified by ``node01`` then we could have a specific template in ``/srv/saltstack/salt/ntp/files/node01/etc/ntp.conf.jinja``.
.. code-block:: jinja
{#- /srv/saltstack/salt/ntp/files/node01/etc/ntp.conf.jinja #}
{#- Managed by saltstack #}
{#- Edit pillars or override this template in saltstack if you need customization #}
{#- Some crazy configurations here for node01 #}
{#- ... #}
To make this work we could write a specially crafted ``conf.sls``.
.. code-block:: sls
## /srv/saltstack/salt-formulas/ntp-saltstack-formula/ntp/conf.sls
include:
- ntp
{%- from 'ntp/map.jinja' import ntp with context %}
Configure NTP:
file.managed:
- name: {{ ntp.config }}
- template: jinja
- source:
- salt://ntp/files/{{ grains.get('id') }}/etc/ntp.conf.jinja
- salt://ntp/files/{{ grains.get('os_family') }}/etc/ntp.conf.jinja
- salt://ntp/files/default/etc/ntp.conf.jinja
- watch_in:
- service: Enable and start NTP service
- require:
- pkg: Install NTP package
Using the ``files_switch`` macro
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
We can simplify the ``conf.sls`` with the new ``files_switch`` macro to use in the ``source`` parameter for the ``file.managed`` state.
.. code-block:: sls
## /srv/saltstack/salt-formulas/ntp-saltstack-formula/ntp/conf.sls
include:
- ntp
{%- set tplroot = tpldir.split('/')[0] %}
{%- from 'ntp/map.jinja' import ntp with context %}
{%- from 'ntp/libtofs.jinja' import files_switch %}
Configure NTP:
file.managed:
- name: {{ ntp.config }}
- template: jinja
- source: {{ files_switch(['/etc/ntp.conf.jinja'],
lookup='Configure NTP'
)
}}
- watch_in:
- service: Enable and start NTP service
- require:
- pkg: Install NTP package
* This uses ``config.get``, searching for ``ntp:tofs:source_files:Configure NTP`` to determine the list of template files to use.
* If this returns a result, the default of ``['/etc/ntp.conf.jinja']`` will be appended to it.
* If this does not yield any results, the default of ``['/etc/ntp.conf.jinja']`` will be used.
In ``libtofs.jinja``, we define this new macro ``files_switch``.
.. literalinclude:: ../template/libtofs.jinja
:caption: /srv/saltstack/salt-formulas/ntp-saltstack-formula/ntp/libtofs.jinja
:language: jinja
How to customise the ``source`` further
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The examples below are based on an ``Ubuntu`` minion called ``theminion`` being configured via. pillar.
Using the default settings of the ``files_switch`` macro above,
the ``source`` will be:
.. code-block:: sls
- source:
- salt://ntp/files/theminion/etc/ntp.conf.jinja
- salt://ntp/files/Debian/etc/ntp.conf.jinja
- salt://ntp/files/default/etc/ntp.conf.jinja
Customise ``files``
~~~~~~~~~~~~~~~~~~~
The ``files`` portion can be customised:
.. code-block:: sls
ntp:
tofs:
dirs:
files: files_alt
Resulting in:
.. code-block:: sls
- source:
- salt://ntp/files_alt/theminion/etc/ntp.conf.jinja
- salt://ntp/files_alt/Debian/etc/ntp.conf.jinja
- salt://ntp/files_alt/default/etc/ntp.conf.jinja
Customise the use of grains
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Grains can be customised and even arbitrary paths can be supplied:
.. code-block:: sls
ntp:
tofs:
files_switch:
- any/path/can/be/used/here
- id
- os
- os_family
Resulting in:
.. code-block:: sls
- source:
- salt://ntp/files/any/path/can/be/used/here/etc/ntp.conf.jinja
- salt://ntp/files/theminion/etc/ntp.conf.jinja
- salt://ntp/files/Ubuntu/etc/ntp.conf.jinja
- salt://ntp/files/Debian/etc/ntp.conf.jinja
- salt://ntp/files/default/etc/ntp.conf.jinja
Customise the ``default`` path
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``default`` portion of the path can be customised:
.. code-block:: sls
ntp:
tofs:
dirs:
default: default_alt
Resulting in:
.. code-block:: sls
- source:
...
- salt://ntp/files/default_alt/etc/ntp.conf.jinja
Customise the list of ``source_files``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The list of ``source_files`` can be given:
.. code-block:: sls
ntp:
tofs:
source_files:
Configure NTP:
- '/etc/ntp.conf_alt.jinja'
Resulting in:
.. code-block:: sls
- source:
- salt://ntp/files/theminion/etc/ntp.conf_alt.jinja
- salt://ntp/files/theminion/etc/ntp.conf.jinja
- salt://ntp/files/Debian/etc/ntp.conf_alt.jinja
- salt://ntp/files/Debian/etc/ntp.conf.jinja
- salt://ntp/files/default/etc/ntp.conf_alt.jinja
- salt://ntp/files/default/etc/ntp.conf.jinja
Note: This does *not* override the default value.
Rather, the value from the pillar/config is prepended to the default.
Using sub-directories for ``components``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If your formula is composed of several components, you may prefer to provides files under sub-directories, like in the `systemd-formula <https://github.com/saltstack-formulas/systemd-formula>`_.
.. code-block:: console
/srv/saltstack/systemd-formula/
systemd/
init.sls
libtofs.jinja
map.jinja
networkd/
init.sls
files/
default/
network/
99-default.link
resolved/
init.sls
files/
default/
resolved.conf
timesyncd/
init.sls
files/
Arch/
resolved.conf
Debian/
resolved.conf
default/
resolved.conf
Ubuntu/
resolved.conf
For example, the following ``formula.component.config`` SLS:
.. code-block:: sls
{%- from "formula/libtofs.jinja" import files_switch with context %}
formula configuration file:
file.managed:
- name: /etc/formula.conf
- user: root
- group: root
- mode: 644
- template: jinja
- source: {{ files_switch(['formula.conf'],
lookup='formula',
use_subpath=True
)
}}
will be rendered on a ``Debian`` minion named ``salt-formula.ci.local`` as:
.. code-block:: sls
formula configuration file:
file.managed:
- name: /etc/formula.conf
- user: root
- group: root
- mode: 644
- template: jinja
- source:
- salt://formula/component/files/salt-formula.ci.local/formula.conf
- salt://formula/component/files/Debian/formula.conf
- salt://formula/component/files/default/formula.conf
- salt://formula/files/salt-formula.ci.local/formula.conf
- salt://formula/files/Debian/formula.conf
- salt://formula/files/default/formula.conf

78
docs/conf.py Normal file
View File

@@ -0,0 +1,78 @@
# Configuration file for the Sphinx documentation builder.
#
# This file only contains a selection of the most common options. For a full
# list see the documentation:
# https://www.sphinx-doc.org/en/master/usage/configuration.html
import os
import sys
# import sphinx_rtd_theme
# import sphinx-material-saltstack # official Salt Sphinx theme
# -- Path setup --------------------------------------------------------------
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#
# import os
# import sys
# sys.path.insert(0, os.path.abspath('.'))
sys.path.insert(0, os.path.abspath('..'))
# -- Project information -----------------------------------------------------
project = 'gitea-formula'
copyright = '2022, lkubb'
author = 'lkubb'
# The full version, including alpha/beta/rc tags
release = '1.0.0'
# -- General configuration ---------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
'sphinx.ext.autosummary',
'sphinx.ext.viewcode',
# 'sphinxcontrib.fulltoc',
]
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
# This pattern also affects html_static_path and html_extra_path.
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
# -- Options for HTML output -------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
#
# html_theme = 'sphinx_rtd_theme'
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
html_theme_options = {
# 'logo_only': False,
# 'display_version': True,
# 'prev_next_buttons_location': 'bottom',
# 'style_external_links': False,
# 'vcs_pageview_mode': '',
# 'style_nav_header_background': 'white',
# Toc options
# 'collapse_navigation': False, # needs sphinxcontrib.fulltoc
# 'sticky_navigation': True,
# 'navigation_depth': 4,
# 'includehidden': True,
# 'titles_only': False
}

20
docs/index.rst Normal file
View File

@@ -0,0 +1,20 @@
Welcome to gitea-formula's documentation!
=========================================
.. toctree::
:maxdepth: 2
:caption: Contents:
README
states
pillar
map.jinja
TOFS_pattern
Indices and tables
==================
* :ref:`genindex`
* :ref:`search`

35
docs/make.bat Normal file
View File

@@ -0,0 +1,35 @@
@ECHO OFF
pushd %~dp0
REM Command file for Sphinx documentation
if "%SPHINXBUILD%" == "" (
set SPHINXBUILD=sphinx-build
)
set SOURCEDIR=.
set BUILDDIR=_build
if "%1" == "" goto help
%SPHINXBUILD% >NUL 2>NUL
if errorlevel 9009 (
echo.
echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
echo.installed, then set the SPHINXBUILD environment variable to point
echo.to the full path of the 'sphinx-build' executable. Alternatively you
echo.may add the Sphinx directory to PATH.
echo.
echo.If you don't have Sphinx installed, grab it from
echo.https://www.sphinx-doc.org/
exit /b 1
)
%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
goto end
:help
%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
:end
popd

542
docs/map.jinja.rst Normal file
View File

@@ -0,0 +1,542 @@
.. _map.jinja:
``map.jinja``: gather formula configuration values
==================================================
The `documentation`_ explains the use of a ``map.jinja`` to gather parameters values for a formula.
As `pillars`_ are rendered on the Salt master for every minion, this increases the load on the master as the pillar values and the number of minions grows.
As a good practice, you should:
- store non-secret data in YAML files distributed by the `fileserver`_
- store secret data in:
- `pillars`_ (and look for the use of something like `pillar.vault`_)
- `SDB`_ (and look for the use of something like `sdb.vault`_)
Current best practice is to let ``map.jinja`` handle parameters from all sources, to minimise the use of pillars, grains or configuration from ``sls`` files and templates directly.
.. contents:: **Table of Contents**
For formula users
-----------------
Quick start: configure per role and per DNS domain name values
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
We will see a quick setup to configure the ``gitea`` formula for different DNS domain names and several roles.
For this example, I'll define 2 kinds of `fileserver`_ sources:
1. formulas git repositories with hard-coded version reference to avoid breaking my setup randomly at upstream update. they are the last sources where files are looked up
2. parameters of the formulas in the file backend `roots`_
Configure the fileserver backends
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I configure the `fileserver`_ backends to serve:
1. files from `roots`_ first
2. `gitfs`_ repositories last
Create the file ``/etc/salt/master.d/fileserver.conf`` and restart the ``master``:
.. code-block:: yaml
---
##
## file server
##
fileserver_backend:
# parameters values and override
- roots
# formulas
- gitfs
# The files in this directory will take precedence over git repositories
file_roots:
base:
- /srv/salt
# List of formulas I'm using
gitfs_remotes:
- https://github.com/saltstack-formulas/template-formula.git:
- base: v4.1.1
- https://github.com/saltstack-formulas/openssh-formula.git:
- base: v2.0.1
...
Create per DNS configuration for ``gitea`` formula
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now, we can provides the per DNS domain name configuration files for the ``gitea`` formulas under ``/srv/salt/gitea/parameters/``.
We create the directory for ``dns:domain`` grain and we add a symlink for the ``domain`` grain which is extracted from the minion ``id``:
.. code-block:: console
mkdir -p /srv/salt/gitea/parameters/dns:domain/
ln -s dns:domain /srv/salt/gitea/parameters/domain
We create a configuration for the DNS domain ``example.net`` in ``/srv/salt/gitea/parameters/dns:domain/example.net.yaml``:
.. code-block:: yaml
---
values:
config: /etc/template-formula-example-net.conf
...
We create another configuration for the DNS domain ``example.com`` in the Jinja YAML template ``/srv/salt/gitea/parameters/dns:domain/example.com.yaml.jinja``:
.. code-block:: yaml
---
values:
config: /etc/template-formula-{{ grains['os_family'] }}.conf
...
Create per role configuration for ``gitea`` formula
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now, we can provides the per role configuration files for the ``gitea`` formulas under ``/srv/salt/gitea/parameters/``.
We create the directory for roles:
.. code-block:: console
mkdir -p /srv/salt/gitea/parameters/roles
We will define 2 roles:
- ``gitea/server``
- ``gitea/client``
We create a configuration for the role ``gitea/server`` in ``/srv/salt/gitea/parameters/roles/gitea/server.yaml``:
.. code-block:: yaml
---
values:
config: /etc/template-formula-server.conf
...
We create another configuration for the role ``gitea/client`` in ``/srv/salt/gitea/parameters/roles/gitea/client.yaml``:
.. code-block:: yaml
---
values:
config: /etc/template-formula-client.conf
...
Enable roles and the ``dns:domain`` and ``domain`` grains for ``map.jinja``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We need to redefine the sources for ``map.jinja`` to load values from our new configuration files, we provide a global configuration for all our minions.
We create the global parameters file ``/srv/salt/parameters/map_jinja.yaml``:
.. code-block:: yaml
---
values:
sources:
# default values
- "Y:G@osarch"
- "Y:G@os_family"
- "Y:G@os"
- "Y:G@osfinger"
- "C@{{ tplroot ~ ':lookup' }}"
- "C@{{ tplroot }}"
# Roles activate/deactivate things
# then thing are configured depending on environment
# So roles comes before `dns:domain`, `domain` and `id`
- "Y:C@roles"
# DNS domain configured (DHCP or resolv.conf)
- "Y:G@dns:domain"
# Based on minion ID
- "Y:G@domain"
# default values
- "Y:G@id"
...
The syntax is explained later at `Sources of configuration values`_.
Bind roles to minions
~~~~~~~~~~~~~~~~~~~~~
We associate roles `grains`_ to minion using `grains.append`_.
For the servers:
.. code-block:: console
salt 'server-*' grains.append roles gitea/server
For the clients:
.. code-block:: console
salt 'client-*' grains.append roles gitea/client
.. note::
Since we used ``Y:C@roles``, ``map.jinja`` will do a ``salt['config.get']('roles')`` to retrieve the roles so you could use any other method to bind roles to minions (`pillars`_ or `SDB`_) but `grains`_ seems to be the preferred method.
Note for Microsoft Windows systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you have a minion running under windows, you can't use colon ``:`` as a delimiter for grain path query (see `bug 58726`_) in which case you should use an alternate delimiter:
Modify ``/srv/salt/parameters/map_jinja.yaml`` to change the query for ``dns:domain`` to define the `alternate delimiter`_:
.. code-block:: yaml
---
values:
sources:
# default values
- "Y:G@osarch"
- "Y:G@os_family"
- "Y:G@os"
- "Y:G@osfinger"
- "C@{{ tplroot ~ ':lookup' }}"
- "C@{{ tplroot }}"
# Roles activate/deactivate things
# then thing are configured depending on environment
# So roles comes before `dns:domain`, `domain` and `id`
- "Y:C@roles"
# DNS domain configured (DHCP or resolv.conf)
- "Y:G:!@dns!domain"
# Based on minion ID
- "Y:G@domain"
# default values
- "Y:G@id"
...
And then, rename the directory:
.. code-block:: console
mv /srv/salt/gitea/parameters/dns:domain/ '/srv/salt/gitea/parameters/dns!domain/'
Format of configuration YAML files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When you write a new YAML file, note that it must conform to the following layout:
- a mandatory ``values`` key to store the configuration values
- two optional keys to configure the use of `salt.slsutil.merge`_
- an optional ``strategy`` key to configure the merging strategy, for example ``strategy: 'recurse'``, the default is ``smart``
- an optional ``merge_lists`` key to configure if lists should be merged or overridden for the ``recurse`` and ``overwrite`` strategy, for example ``merge_lists: 'true'``
Here is a valid example:
.. code-block:: yaml
---
strategy: 'recurse'
merge_lists: 'false'
values:
pkg:
name: 'some-package'
config: '/path/to/a/configuration/file'
...
Using Jinja2 YAML template
~~~~~~~~~~~~~~~~~~~~~~~~~~
You can provide a Jinja2 YAML template file with a name suffixed with ``.yaml.jinja``, it must produce a YAML file conform to the `Format of configuration YAML files`_, for example:
.. code-block:: jinja
---
strategy: 'overwrite'
merge_lists: 'true'
values:
{%- if grains["os"] == "Debian" %}
output_dir: /tmp/{{ grains["id"] }}
{%- endif %}
...
Sources of configuration values
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``map.jinja`` file aggregates configuration values from several sources:
- YAML files stored in the `fileserver`_
- `pillars`_
- `grains`_
- configuration gathered with `salt['config.get']`_
For the values loaded from YAML files, ``map.jinja`` will automatically try to load a Jinja2 template with the same name as the YAML file with the addition of the ``.jinja`` extension, for example ``foo/bar/quux.yaml.jinja``.
After loading values from all sources, it will try to include the ``salt://{{ tplroot }}/post-map.jinja`` Jinja file if it exists which can post-process the ``mapdata`` variable.
Configuring ``map.jinja`` sources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``map.jinja`` file uses several sources where to lookup parameter values. The list of sources can be configured in two places:
1. globally
1. with a plain YAML file ``salt://parameters/map_jinja.yaml``
2. with a Jinja2 YAML template file ``salt://parameters/map_jinja.yaml.jinja``
2. per formula
1. with a plain YAML file ``salt://{{ tplroot }}/parameters/map_jinja.yaml``
2. with a Jinja2 YAML template file ``salt://{{ tplroot }}/parameters/map_jinja.yaml.jinja``
.. note::
The ``map.jinja`` configuration files must conform to the `format of configuration YAML files`_.
Each source definition has the form ``[<TYPE>[:<OPTION>[:<DELIMITER>]]@]<KEY>`` where ``<TYPE>`` can be one of:
- ``Y`` to load values from YAML files from the `fileserver`_, this is the default when no type is defined
- ``C`` to lookup values with `salt['config.get']`_
- ``G`` to lookup values with `salt['grains.get']`_
- ``I`` to lookup values with `salt['pillar.get']`_
The YAML type option can define the query method to lookup the key value to build the file name:
- ``C`` to query with `salt['config.get']`_, this is the default when no query method is defined
- ``G`` to query with `salt['grains.get']`_
- ``I`` to query with `salt['pillar.get']`_
The ``C``, ``G`` or ``I`` types can define the ``SUB`` option to store values in the sub key ``mapdata.<KEY>`` instead of directly in ``mapdata``.
All types can define the ``<DELIMITER>`` option to use an `alternate delimiter`_ of the ``<KEY>``, for example: on windows system you can't use colon ``:`` for YAML file path name and you should use something else like exclamation mark ``!``.
Finally, the ``<KEY>`` describes what to lookup to either build the YAML filename or gather values using one of the query methods.
.. note::
For the YAML type:
- if the ``<KEY>`` can't be looked up, then it's used a literal string path to a YAML file, for example: ``any/path/can/be/used/here.yaml`` will result in the loading of ``salt://{{ tplroot }}/parameters/any/path/can/be/used/here.yaml`` if it exists
- ``map.jinja`` will automatically try to load a Jinja2 template, after the corresponding YAML file, with the same name as the YAML file extended with the ``.jinja`` extension, for example ``any/path/can/be/used/here.yaml.jinja``
The built-in ``map.jinja`` sources are:
.. code-block:: yaml
- "Y:G@osarch"
- "Y:G@os_family"
- "Y:G@os"
- "Y:G@osfinger"
- "C@{{ tplroot ~ ':lookup' }}"
- "C@{{ tplroot }}"
- "Y:G@id"
This is strictly equivalent to the following ``map_jinja.yaml.jinja``:
.. code-block:: sls
values:
sources:
- "parameters/osarch/{{ salt['grains.get']('osarch') }}.yaml"
- "parameters/osarch/{{ salt['grains.get']('osarch') }}.yaml.jinja"
- "parameters/os_family/{{ salt['grains.get']('os_family') }}.yaml"
- "parameters/os_family/{{ salt['grains.get']('os_family') }}.yaml.jinja"
- "parameters/os/{{ salt['grains.get']('os') }}.yaml"
- "parameters/os/{{ salt['grains.get']('os') }}.yaml.jinja"
- "parameters/osfinger/{{ salt['grains.get']('osfinger') }}.yaml"
- "parameters/osfinger/{{ salt['grains.get']('osfinger') }}.yaml.jinja"
- "C@{{ tplroot ~ ':lookup' }}"
- "C@{{ tplroot }}"
- "parameters/id/{{ salt['grains.get']('id') }}.yaml"
- "parameters/id/{{ salt['grains.get']('id') }}.yaml.jinja"
Loading values from the configuration sources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For each configuration source defined, ``map.jinja`` will:
#. load values depending on the source type:
- for YAML file sources
- if the ``<KEY>`` can be looked up:
- load values from the YAML file named ``salt://{{ tplroot }}/paramaters/<KEY>/{{ salt['<QUERY_METHOD>']('<KEY>') }}.yaml`` if it exists
- load values from the Jinja2 YAML template file named ``salt://{{ tplroot }}/paramaters/<KEY>/{{ salt['<QUERY_METHOD>']('<KEY>') }}.yaml.jinja`` if it exists
- otherwise:
- load the YAML file named ``salt://{{ tplroot }}/parameters/<KEY>.yaml`` if it exists
- load the Jinja2 YAML template file named ``salt://{{ tplroot }}/parameters/<KEY>.yaml.jinja`` if it exists
- for ``C``, ``G`` or ``I`` source type, lookup the value of ``salt['<QUERY_METHOD>']('<KEY>')``
#. merge the loaded values with the previous ones using `salt.slsutil.merge`_
There will be no error if a YAML or Jinja2 file does not exists, they are all optional.
Configuration values from ``salt['config.get']``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For sources with of type ``C`` declared in ``map_jinja:sources``, you can configure the ``merge`` option of `salt['config.get']`_ by defining per formula ``strategy`` configuration key (retrieved with ``salt['config.get'](tplroot ~ ':strategy')`` with one of the following values:
- ``recurse`` merge recursively dictionaries. Non dictionary values replace already defined values
- ``overwrite`` new value completely replace old ones
By default, no merging is done, the first value found is returned.
Global view of the order of preferences
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To summarise, here is a complete example of the load order of formula configuration values for an ``AMD64`` ``Ubuntu 18.04`` minion named ``minion1.example.net`` for the ``libvirt`` formula:
#. ``parameters/defaults.yaml``
#. ``parameters/defaults.yaml.jinja``
#. ``parameters/osarch/amd64.yaml``
#. ``parameters/osarch/amd64.yaml.jinja``
#. ``parameters/os_family/Debian.yaml``
#. ``parameters/os_family/Debian.yaml.jinja``
#. ``parameters/os/Ubuntu.yaml``
#. ``parameters/os/Ubuntu.yaml.jinja``
#. ``parameters/osfinger/Ubuntu-18.04.yaml``
#. ``parameters/osfinger/Ubuntu-18.04.yaml.jinja``
#. ``salt['config.get']('libvirt:lookup')``
#. ``salt['config.get']('libvirt')``
#. ``parameters/id/minion1.example.net.yaml``
#. ``parameters/id/minion1.example.net.yaml.jinja``
Remember that the order is important, for example, the value of ``key1:subkey1`` loaded from ``parameters/os_family/Debian.yaml`` is overridden by a value loaded from ``parameters/id/minion1.example.net.yaml``.
For formula authors and contributors
------------------------------------
Dependencies
^^^^^^^^^^^^
``map.jinja`` requires:
- salt minion 2018.3.3 minimum to use the `traverse`_ jinja filter
- to be located at the root of the formula named directory (e.g. ``libvirt-formula/libvirt/map.jinja``)
- the ``libsaltcli.jinja`` library, stored in the same directory, to disable the ``merge`` option of `salt['config.get']`_ over `salt-ssh`_
- the ``libmapstack.jinja`` library to load the configuration values
- the ``libmatchers.jinja`` library used by ``libmapstack.jinja`` to parse compound like matchers
Use formula configuration values in ``sls``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``map.jinja`` exports a unique ``mapdata`` variable which could be renamed during import.
Here is the best way to use it in an ``sls`` file:
.. code-block:: sls
{#- Get the `tplroot` from `tpldir` #}
{%- set tplroot = tpldir.split("/")[0] %}
{%- from tplroot ~ "/map.jinja" import mapdata as gitea with context %}
test-does-nothing-but-display-gitea-as-json:
test.nop:
- name: {{ gitea | json }}
Use formula configuration values in templates
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When you need to process salt templates, you should avoid calling `salt['config.get']`_ (or `salt['pillar.get']`_ and `salt['grains.get']`_) directly from the template. All the needed values should be available within the ``mapdata`` variable exported by ``map.jinja``.
Here is an example based on `template-formula/gitea/config/file.sls`_:
.. code-block:: sls
# -*- coding: utf-8 -*-
# vim: ft=sls
{#- Get the `tplroot` from `tpldir` #}
{%- set tplroot = tpldir.split('/')[0] %}
{%- set sls_package_install = tplroot ~ '.package.install' %}
{%- from tplroot ~ "/map.jinja" import mapdata as gitea with context %}
{%- from tplroot ~ "/libtofs.jinja" import files_switch with context %}
include:
- {{ sls_package_install }}
gitea-config-file-file-managed:
file.managed:
- name: {{ gitea.config }}
- source: {{ files_switch(['example.tmpl'],
lookup='gitea-config-file-file-managed'
)
}}
- mode: 644
- user: root
- group: {{ gitea.rootgroup }}
- makedirs: True
- template: jinja
- require:
- sls: {{ sls_package_install }}
- context:
gitea: {{ gitea | json }}
This ``sls`` file expose a ``gitea`` context variable to the jinja template which could be used like this:
.. code-block:: jinja
########################################################################
# File managed by Salt at <{{ source }}>.
# Your changes will be overwritten.
########################################################################
This is another example file from SaltStack template-formula.
# This is here for testing purposes
{{ gitea | json }}
winner of the merge: {{ gitea['winner'] }}
.. _documentation: https://docs.saltproject.io/en/latest/topics/development/conventions/formulas.html#writing-formulas
.. _fileserver: https://docs.saltproject.io/en/latest/ref/file_server
.. _salt['config.get']: https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.config.html#salt.modules.config.get
.. _salt['grains.get']: https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.grains.html#salt.modules.grains.get
.. _salt['pillar.get']: https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.pillar.html#salt.modules.pillar.get
.. _alternate delimiter: https://docs.saltproject.io/en/latest/topics/targeting/compound.html#alternate-delimiters
.. _pillar.vault: https://docs.saltproject.io/en/latest/ref/pillar/all/salt.pillar.vault.html
.. _pillars: https://docs.saltproject.io/en/latest/topics/pillar/
.. _grains: https://docs.saltproject.io/en/latest/topics/grains/
.. _grains.append: https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.grains.html#salt.modules.grains.append
.. _SDB: https://docs.saltproject.io/en/latest/topics/sdb/index.html
.. _sdb.vault: https://docs.saltproject.io/en/latest/ref/sdb/all/salt.sdb.vault.html
.. _Jinja: https://docs.saltproject.io/en/latest/topics/jinja
.. _roots: https://docs.saltproject.io/en/latest/ref/file_server/all/salt.fileserver.roots.html
.. _gitfs: https://docs.saltproject.io/en/latest/topics/tutorials/gitfs.html
.. _salt.slsutil.merge: https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.slsutil.html#salt.modules.slsutil.merge
.. _traverse: https://docs.saltproject.io/en/latest/topics/jinja/index.html#traverse
.. _salt-ssh: https://docs.saltproject.io/en/latest/topics/ssh/
.. _template-formula/gitea/config/file.sls: https://github.com/saltstack-formulas/template-formula/blob/master/gitea/config/file.sls
.. _bug 58726: https://github.com/saltstack/salt/issues/58726

7
docs/pillar.rst Normal file
View File

@@ -0,0 +1,7 @@
.. _pillar.example:
Example Pillar
==============
.. literalinclude:: ../pillar.example
:language: yaml

6
docs/states.rst Normal file
View File

@@ -0,0 +1,6 @@
Available States
================
The following states are found in this formula: