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 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.

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.

3.2 KiB Raw Blame History