Approve directory locations suitable for production usage & backups

RESOLVED FIXED

Status

Developer Services
General
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: hwine, Unassigned)

Tracking

Details

(Whiteboard: [reit-b2g], URL)

(Reporter)

Description

5 years ago
The hg<->git conversion process needs to move out of /home and into directories on the local SSD disk.

There are at least 4 categories of data to be stored:
 - executables (bash scripts, cronjob scripts)
 - configuration files 
 - data (expensive to recreate > 6day CPU time)
 - passphrase protected private keys for pushing to repositories

Please suggest a directory layout for each of these that is compliant with all applicable policies.

The latest, but still-being-developed draft description of the system is linked via the URL field for more information.
Does this process have a name?
Assignee: server-ops → server-ops-devservices
Component: Server Operations → Server Operations: Developer Services
QA Contact: jdow → shyam
(Reporter)

Comment 2

5 years ago
Fifth category of data:
 - log files
(Reporter)

Comment 3

5 years ago
(In reply to Shyam Mani [:fox2mike] from comment #1)
> Does this process have a name?

There is no "process", in the sense of a long running job name. We can make up a name to cover the suite of processes as a name for a directory tree. "hg-git" is reasonable for that.

I was expecting to get pointed to a "best practices" or conventions doc (such as the Linux FSSTND) - something to resolve the "/opt/fu" vs "/usr/local/fu" vs XXXX questions. Are config files kept in "/etc/opt" or "/opt/etc", etc.
We don't have a standard policy as such.

That said, everything that's project specific can live in /opt/$projectname

Configs can be in /etc/$projectname

Logs can go to /var/log/$projectname

Therefore this is easier to do with a projectname :D Or a name. I'm not sure hg-git is good enough because some other teams are working on the reverse bits and it's easy to get confused.

Does that help answer the questions you had?
(Reporter)

Comment 5

5 years ago
I believe all questions are answered. The proof is if IT agrees on the following structure & backup requirements. :)

In pseudo bash:

    $serviceName=convererator # (or vcs2vcs)
    $serviceUser=??? (tbd bug 791169)

    install -o root -d /opt/$serviceName
    install -o $serviceUser -d /opt/$serviceName/{bin,lib,etc,repos,venv}
    install -o $serviceUser -m 0700 -d /opt/$serviceName/keys
    install -o $serviceUser -d /var/log/$serviceName

    ( cd /etc && ln -s ../opt/$serviceName/etc $serviceName )
    ( cd /opt/$serviceName && ln -s ../../var/log/serviceName log )

Expectation is:
 - MUST be backed up on regular (daily) basis:
    /opt/$serviceName/repos/*
    /var/log/$serviceName/*
 - everything else can be recreated from repositories
(Reporter)

Comment 6

5 years ago
change summary to reflect where this has morphed to. Waiting on confirmation or corrections to proposed directory layout.
Summary: Propose directory locations suitable for production usage → Approve directory locations suitable for production usage & backups
r+ on all the above. I'm not sold on the name as such and we will backup everything under /opt/$serviceName/* and /var/log/$serviceName/*
Just had a chat with hwine on IRC, this is going to be called vcs2vcs
Directory structure has been approved, hwine will handle the transitioning.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Component: Server Operations: Developer Services → General
Product: mozilla.org → Developer Services
You need to log in before you can comment on or make changes to this bug.