87 lines
3.2 KiB
ReStructuredText
87 lines
3.2 KiB
ReStructuredText
Guidelines
|
|
==========
|
|
|
|
|
|
Version Control
|
|
---------------
|
|
|
|
Everything must be in version control before being used on production systems.
|
|
In particular, scripts and other software, SPEC files for packages, relevant
|
|
documentation, Puppet code, etc.
|
|
|
|
Git Hooks
|
|
---------
|
|
|
|
`This repository <https://gitern.psi.ch/linux-infra-software/githooks>`_ provides a pre-commit git hook that checks code compliance to different standards.
|
|
|
|
Hiera Code
|
|
----------
|
|
|
|
The naming of the variables inside Hiera depends on the scope usage of the variables.
|
|
|
|
The variables beeing used only inside one specific class
|
|
will be named ``base_class_name::variable`` where ``base_class_name`` is the last part of class name, without the part before the last ``::`` separator.
|
|
Eg. the ``permit_root_login`` variable for the ``profile::ssh_server`` class will be named ``ssh_server::permit_root_login``.
|
|
|
|
When a variable is shared between a client and a server, we will prepend the variable name with the service name.
|
|
Eg. the ``grid_name`` parameter for ganglia service, used inside both client and server configuration, will be named ``ganglia::grid_name``.
|
|
|
|
*Note:* this could potentially bring to conflicts, if we want to specify hiera values to be used both inside roles and profiles with the same name.
|
|
Do we want that?
|
|
|
|
|
|
Code Reviews
|
|
------------
|
|
|
|
All code must be reviewed by at least one other team member with write access to
|
|
the repository before pushing it. This will help keep the style consistent and
|
|
increase familiarity with the code base.
|
|
|
|
|
|
External Code
|
|
-------------
|
|
|
|
Although the installation infrastructure makes large usage of external code the system
|
|
has to avoid as much as possible dependency from external services availability.
|
|
A WAN outage or a remote http server failure should not influence the installation system.
|
|
For this reason, all the external code is mirrored internally in specific git repositories.
|
|
|
|
|
|
Servers and services
|
|
--------------------
|
|
|
|
Every server should support exactly one service, e.g. Puppet, or FTP. This makes
|
|
the services more independent (e.g. for downtimes), simplifies the structure of
|
|
the corresponding Puppet code, makes it easier to reason about the environment,
|
|
and prevents conflicts regarding certain configuration settings.
|
|
|
|
|
|
Development Workflow
|
|
--------------------
|
|
|
|
The general inspiration comes from `this post
|
|
<http://nvie.com/posts/a-successful-git-branching-model/>`_.
|
|
|
|
|
|
Naming convention for servers
|
|
-----------------------------
|
|
|
|
Server names have the form ``lx-purpose-[0-9][0-9].psi.ch``, where
|
|
``purpose`` is the purpose of the server or the service provided by it. Examples are:
|
|
|
|
- ``lx-boot-01.psi.ch`` is the **boot** server
|
|
|
|
The production server always has an DNS alias `purpose.psi.ch` and clients should always use this alias to connect to the server.
|
|
|
|
When putting system names into configuration files, we always use lower case and
|
|
the fully qualified domain name. Good: ``boot.psi.ch``.
|
|
|
|
|
|
Names for programs
|
|
------------------
|
|
|
|
Scripts should not include a suffix indicating
|
|
the language they are written in. The latter is an implementation detail and
|
|
does not matter to the caller of the script/program. A good name could be
|
|
``pli-system-info``, a bad one would be ``pli-system-info.sh``.
|