@opentermsarchive/engine 0.16.0 → 0.17.1

package/decision-records/0002-service-history.md

@@ -1,212 +0,0 @@
-# Defining a service history system
-
-- Date: 2020-11-23
-
-## Context and Problem Statement
-
-We need to be able to regenerate versions from snapshots. As documents is aim to change over time (location or filters) we can't rely on the last version of the declaration to regenerate the version from an old snapshot. So we need a system to keep track of declaration changes, that's what we called declarations and filters versioning.
-
-## Solutions considered
-
-At this time, we see three solutions which have in common the following rules:
-
-- `history` is optional
-- the current valid declaration has no date and should be clearly identifiable
-- the `valid_until` date is an inclusive expiration date. It should be the exact authored date of the last snapshot commit for which the declaration is still valid.
-
-## Option 1: Add an `history` field in service declaration
-
-In `services/ASKfm.json`:
-
-```
-{
-  "name": "ASKfm",
-  "documents": {
-    "Terms of Service": {
-      "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-      "select": ".selection",
-      "filter": [ "add" ]
-      "history": [
-        {
-          "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-          "select": "body",
-          "filter": [ "add" ]
-          "valid_until": "2020-08-24T14:02:39Z"
-        },
-        {
-          "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-          "select": "body",
-          "valid_until": "2020-08-23T14:02:39Z"
-        }
-      ]
-    }
-  }
-}
-```
-
-Note: When no historisation is needed the file may have no mention of history.
-
-**Pros:**
-
-- Everything is in the same file:
-  - might prevent to forget to update existing history
-  - might help user to know that history is a thing and encourage them to learn about it if they feel the need
-  - no (pseudo-)hidden knowledge about history
-
-**Cons:**
-
-- Apparent complexity can discourage new contributors
-- With time, the file can become huge
-
-## Option 2: Add an `serviceId.history.json` file
-
-In `services/ASKfm.json`:
-
-```
-{
-  "name": "ASKfm",
-  "documents": {
-    "Terms of Service": {
-      "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-      "select": ".selection",
-      "filter": [ "add" ]
-    }
-  }
-}
-```
-
-In `services/ASKfm.history.json`:
-
-```
-{
-  "name": "ASKfm",
-  "documents": {
-    "Terms of Service": [
-      {
-        "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-        "select": "body",
-        "filter": [ "add" ]
-        "valid_until": "2020-08-24T14:02:39Z"
-      },
-      {
-        "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-        "select": "body",
-        "valid_until": "2020-08-23T14:02:39Z"
-      }
-    ]
-  }
-}
-```
-
-**Pros:**
-
-- Service declaration stay small and simple
-- History file is kept close to the service declaration so users might see them
-
-**Cons:**
-
-- Make the discovery of history capacities less easy
-- Increase the probability of forgetting to update history file when making a change in the service discovery
-
-## Option 2A
-
-Same as option 2, but the history file should only contain the document declarations to avoid divergence on service properties with the one in the original file.
-
-In `services/ASKfm.json`, **called the “service declaration”**:
-
-```
-{
-  "name": "ASKfm",
-  "documents": {
-    "Terms of Service": {
-      "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-      "select": ".selection",
-      "filter": [ "add" ]
-    }
-  }
-}
-```
-
-In `services/ASKfm.history.json`, **called the “service history”**:
-
-```
-{
-  "Terms of Service": [
-    {
-      "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-      "select": "body",
-      "filter": [ "add" ]
-      "valid_until": "2020-08-24T14:02:39Z"
-    },
-    {
-      "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-      "select": "body",
-      "valid_until": "2020-08-23T14:02:39Z"
-    }
-  ]
-}
-```
-
-## Option 3: Add an history service declaration file in `services/history` folder
-
-In `services/ASKfm.json`:
-
-```
-{
-  "name": "ASKfm",
-  "documents": {
-    "Terms of Service": {
-      "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-      "select": ".selection",
-      "filter": [ "add" ]
-    }
-  }
-}
-```
-
-In `services/history/ASKfm.json`:
-
-```
-{
-  "name": "ASKfm",
-  "documents": {
-    "Terms of Service": [
-      {
-        "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-        "select": "body",
-        "filter": [ "add" ]
-        "valid_until": "2020-08-24T14:02:39Z"
-      },
-      {
-        "fetch": "https://ask.fm/docs/terms_of_use/?lang=en",
-        "select": "body",
-        "valid_until": "2020-08-23T14:02:39Z"
-      }
-    ]
-  }
-}
-```
-
-**Pros:**
-
-- Service declaration stay small and simple
-- All history updates are reserved to users with the knowledge that might work as gatekeepers
-
-**Cons:**
-
-- All history updates are reserved to users with the knowledge that might work as gatekeepers :)
-- Need to rely on people with knowledge to keep the history
-
-## Some thoughts
-
-### Community
-
-The choice might have implication on the community that will grow around the project.
-
-_Option 1_ shows everything to everyone, it might frightened some contributors with some apparent complexity (once there are history in the declaration file), but it might also encourage them to learn about it if they want or feel the need to. All contributors will share the same view and knowledge about the system. This might encourage collaboration between them to learn and improve together.
-
-_Option 2_ and _Option 3_ hide the complexity of history management in separate files and only most adventurous contributors will find them by themselves. Contribution to those files will probably be done by specific contributors that will be taught to manage those file. Thus creating two different kind of contributors: those who will stay with the basic service declaration, not knowing that more complex options exist, and those who will have the knowledge of history management whose work might stay in the shadow or work as gatekeeper.
-
-## Decision Outcome
-
-[After consulting the community](https://github.com/ambanum/OpenTermsArchive/issues/156), the options 2A is retained as it hide complexity (compared to Option 1) of the history while increasing its discoverability (compared to Option 3) for contributors who might become more “adventurous”.

package/decision-records/0003-snapshots-database.md

@@ -1,123 +0,0 @@
-# Determining an appropriate database system to store snapshots
-
-- Date: 2021-10-20
-
-## Context and Problem Statement
-
-### Context
-
-The Versions repository has several purposes:
-
-- Display differences between two versions, in particular when users receive a notification of change, so that they can simply see the changes.
-- Explore significant changes in tracked documents.
-- Offer a corpus of the latest versions of all the documents of the monitored services.
-- Serve as a dataset for research.
-
-It is therefore important that repository constitutes a quality dataset, to provide relevant information to users.
-
-For this purpose, the following constraints are considered necessary:
-
-- Versions must be ordered chronologically, so that navigation through the history of a document is intuitive.
-- Versions should not contain noise, only significant changes.
-- Each version must contain a link to the snapshot that was used to generate it.
-
-Currently, the following problems with the repository of Versions are identified:
-
-- Noise in the versions: URL or structure changes in the tracked documents.
-- Presence of refilter commits: related to URL and selector updates in service declarations or to Open Terms Archive code evolution.
-- Presence of commits due to code changes: type renaming, service renaming, documentation changes in the repository.
-- Presence of unordered commits: consequence of the import of the ToSBack history in snapshots or to the import of snapshots corresponding to archived documents provided by the services themselves.
-
-The solution considered in order to provide a quality dataset therefore consists of being able to regenerate the `versions` from the `snapshots`, that's what we call rewriting history.
-
-#### Rewriting history
-
-To rewrite history, we go through the snapshot commits one by one after reordering them (in memory) and we create a version commit each time, avoiding commits corresponding to noise and performing any renaming.
-
-This implies being able to version the service filters (used to generate the version from the snapshot).
-See https://github.com/ambanum/OpenTermsArchive/issues/156.
-
-### Problem
-
-Currently, `git` is used as database for storing snapshots and versions.
-One year ago, the process to rewrite history was estimated to take about 16 hours for 100,000 commits. It has also been noted that the evolution of the time is not linear, the more commits there are in `snapshots` the more the average time per commit increases.
-
-It appears that the most costly operation is accessing the contents of a commit (checkout).
-It also appears that the older the commit is in the git history, the longer this operation takes.
-
-> For example, on a history containing about 100,000 commits, accessing the contents of the oldest commit takes about 1,000 ms while accessing the most recent commit takes only 100 ms.
-
-At the date of this document, the number of commits entries approaches the million and to iterate over these snapshots, to rewrite versions history, it currently takes more or less 3 months.
-
-
-Also, `git` implies to store data in a hash tree in the form of chronologically ordered commits. So to insert snapshots in the history, it implies to rewrite the whole snapshots history which also takes the same time as reading them.
-
-As described previously, we need to be able to regenerate versions from snapshots (for example to [rename services](https://github.com/ambanum/OpenTermsArchive/issues/314)) and to be able to insert snapshots in the history (for example to [import databases](https://github.com/ambanum/OpenTermsArchive/pull/214)).
-**This cannot take 6 months.**
-
-Moreover, as the number of snapshots will keep on growing, we need a system which allows scaling, potentially across multiple servers.
-
-Thus, we need a database management system meeting the following requirements:
-
-- Access time to a snapshot should be constant and independent from its authoring date.
-- Inserting time of a snapshot should be constant and independent from its authoring date.
-- Support concurrent access.
-- Scale horizontally.
-
-### Solutions considered
-
-#### 1. Keep the system under git
-
-##### Splitting into sub-repos
-
-Since accessing the contents of a commit takes longer the older it is in the history considered, the idea would be to work successively on ordered subsets of this history.
-This means truncating the history, browsing the remaining commits and regenerating the corresponding versions. Then creating another subset of the history which contains an arbitrary number of commits following the commits already browsed and perform the processing.
-
-To create a history subset with git :
-- Create a clone of a subset of N commits from the local snapshot: `git clone --depth <N> "file://local/path/snapshots" snapshots-tmp` with `N` corresponding to the position of the first commit you want in the block relative to the last commit in the history
-- Remove all commits older than the last commit you want to keep in the block: `git reset --hard <sha>` with `sha` corresponding to the id of the last commit you want to have in the block.
-- Clean up git to ensure that history navigation is efficient: `git gc`.
-
-So we need to split the history into chronologically ordered blocks, which leads us to the next problem.
-
-##### Splitting and reordering blocks of snapshots
-
-Because snapshot commits are unordered, we can't simply create blocks of a fixed size from the git history (otherwise we'd process commits out of order).
-It is necessary to create blocks whose commits are ordered within the block but also in relation to the other blocks: for example, all the commits of the first block processed must be older than the commits of all the other blocks.
-
-The solution would be to create blocks in order: from the git history, we look for commits that are not in their place (whose date is earlier than that of its predecessor).
-
-Each of these commits represents the first commit of a block. This block extends to the previous one, the starting point of the next block.
-We thus obtain blocks whose commits are ordered.
-
-We still have to order the blocks between them (note, it is possible to have to cut a block to be able to place another).
-
-These chronologically ordered commit blocks, without overlap, can then be used with the previous approach (it may be necessary to re-split these blocks so that they have a reasonable size).
-
-#### 2. Move snapshots to a document-oriented database
-
-The idea of this solution is to keep the `versions` under git in order to continue to enjoy the benefits that GitHub provides in terms of browsing and viewing diffs, but to save the snapshots in a database, since we don't really need to browse the snapshots via a graphical interface nor to see the diff between two snapshots, which would allow us to be able to access the content more efficiently.
-
-MongoDB seems to meet the constraints:
-
-- It natively allows horizontal scaling with [replica sets](https://docs.mongodb.com/manual/replication/) and [sharding](https://docs.mongodb.com/manual/sharding/).
-- It supports concurrent access.
-- It has [In-Memory storage engine](https://docs.mongodb.com/manual/core/inmemory/) as an option for performance.
-
-We also did a simple test to ensure that access time and insert time also meets the requirements. We populated a database with one million entries and tried accessing snapshots with random dates and we found that access times remained stable. In our test on 1000 sequential access to random snapshot, the average access time was ~3.5ms with a maximum of ~50ms.
-
-Moreover, MongoDB has the following benefits:
-
-- Easy to use: offers a simple query syntax SQL and has a quick learning curve, especially for JavaScript developers.
-- Flexible and evolutive: allows to manage data of any structure, not just tabular structures defined in advance.
-- Widely used in the JavaScript ecosystem.
-
-As downside, joining documents in MongoDB is no easy task and pulling data from several collections requires a number of queries, which will lead to long turn-around times. This is not a problem in our case as we do not currently envision a need for such complex queries.
-
-## Decision Outcome
-
-As MongoDB meets the requirements it is retained as a solution.
-
-### Benchmark
-
-With MongoDB implementation, refilter takes around ~3m where it took around ~1h20 with the Git version.

package/ops/README.md

@@ -1,280 +0,0 @@
-# Open Terms Archive Ops
-
-Recipes to set up the infrastructure of and deploy Open Terms Archive.
-
-## Requirements
-
-1. Install [Ansible](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html).
-2. Install [Vagrant](https://www.vagrantup.com/downloads).
-3. Install [VirtualBox](https://www.virtualbox.org/wiki/Downloads) to manage virtual machines. If you prefer Docker, or have an Apple Silicon machine, install [Docker](https://docs.docker.com/get-docker/) instead.
-4. Create a dedicated SSH key with no password: `ssh-keygen -f ~/.ssh/ota-vagrant -q -N ""`. This key will be automatically used by Vagrant.
-
-> VirtualBox is not compatible with Apple Silicon (M1…) processors. If you have such a machine, you will need to use the Docker provider. Since MongoDB cannot be installed on ARM, it is skipped in the infrastructure installation process. This means you cannot test the MongoDB storage repository with Vagrant with an Apple Silicon processor.
-
-## Usage
-
-**You should never apply changes to production from your machine.** We use continuous deployment to apply changes. To avoid making changes on the production server by mistake, we use [Vagrant](https://www.vagrantup.com) to describe and spawn virtual machines. By default all commands will only affect the Vagrant development virtual machine (VM).
-
-### Launch
-
-If you’re on an Apple Silicon processor or want to use Docker instead of VirtualBox, use `vagrant up --provider=docker`.
-
-In all other cases, use `vagrant up` 🙂
-
-You can then deploy the code to the running machine with all the options described below.
-
-### Main commands
-
-- To set up a full [(phoenix)](https://martinfowler.com/bliki/PhoenixServer.html) server:
-
-```
-ansible-playbook ops/site.yml
-```
-
-- To setup the infrastructure only:
-
-```
-ansible-playbook ops/infra.yml
-```
-
-- To setup the `Open Terms Archive` app only:
-
-```
-ansible-playbook ops/app.yml
-```
-
-### Vagrant quick reference
-
-#### Connect to the virtual machine
-
-```
-vagrant up
-vagrant ssh  # use "vagrant" as password
-```
-
-#### Start again with a clean virtual machine
-
-```
-vagrant halt  # stop machine
-vagrant destroy  # remove machine
-vagrant up
-```
-
-#### Troubleshooting: Remote host identification has changed
-
-In case you get that kind of error:
-
-```
-fatal: [127.0.0.1]: UNREACHABLE! => changed=false
-  msg: |-
-    Failed to connect to the host via ssh: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
-    @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
-    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
-    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
-    …
-  unreachable: true
-```
-
-It may be because you already have a `known_host` registered with the same IP and port. To solve this, remove it from the entries using `ssh-keygen -R [127.0.0.1]:2222`.
-
-#### Troubleshooting: Connection refused
-
-If you have the following error:
-
-```
-Failed to connect to the host via ssh: ssh: connect to host 127.0.0.1 port 2222: Connection refused
-```
-
-You may have a collision on the default port `2222` used by Vagrant to forward SSH commands.
-Run the following command to know which ports are forwarded for the virtual machine:
-
-```
-vagrant port
-```
-
-It should display something like that:
-
-```
-The forwarded ports for the machine are listed below. Please note that
-these values may differ from values configured in the Vagrantfile if the
-provider supports automatic port collision detection and resolution.
-
-    22 (guest) => 2200 (host)
-```
-
-Modify the Ansible SSH options in the `ops/inventories/dev.yml` file with the proper `ansible_ssh_port`:
-
-```
-all:
-  children:
-    vagrant:
-      hosts:
-        127.0.0.1:
-          […]
-          ansible_ssh_port: 2200
-          […]
-```
-
-### Logs
-
-You can obtain logs from the process manager over SSH:
-
-```
-ssh <user>@<instance_hostname> pm2 logs ota
-```
-
-### Tags
-
-Some tags are available to refine what will happen, use them with `--tags`:
-
-- `setup`: to only setup system dependencies required by the app (cloning repo, installing app dependencies, all config files, and so on…)
-- `start`: to start the app
-- `stop`: to stop the app
-- `restart`: to restart the app
-- `update`: to update the app (pull code, install dependencies and restart app)
-- `update-declarations`: to update services declarations (pull declarations, install dependencies and restart app)
-
-For example, if you have changes to the core engine to deploy but no infrastructure changes, you can update the app only by running:
-
-```
-ansible-playbook ops/app.yml --tags update --limit <instance_name>
-```
-
-## Production
-
-### Applying changes
-
-To test locally your changes to the playbook before opening a pull request:
-
-- Remove all traces of previous tests to ensure that your changes do not work by coincidence: `vagrant destroy && vagrant up`.
-- Start by applying your changes on the virtual machine: `ansible-playbook ops/site.yml`.
-- Connect through SSH to the virtual machine and check that everything works as intended: `vagrant ssh`, `pm2 logs`…
-- Open a pull request and wait for it to be reviewed and merged. The continuous deployment process will take care of applying your changes to every production instance.
-
-### Deploying manually from your machine
-
-**You should not be doing this.** If something terrible is happening in production, did you try just stopping the instance? Any fix should be applied through a PR and deployed in CD to ensure reproducibility.
-
-Note that executing the playbook on the `production` inventory will affect **all** production servers. Unless you know exactly what you are doing, you should always execute a playbook on a specific server only, add the `--limit` option with the instance name defined in `ops/inventories/production.yml` as parameter:
-
-```
-ansible-playbook --inventory ops/inventories/production.yml ops/site.yml --limit <instance_name>
-```
-
-### Allowed keys
-
-Setting up the production infrastructure for publishing on the shared versions repository entails decrypting a private key managed with [Ansible Vault](https://docs.ansible.com/ansible/latest/user_guide/vault.html). It is decrypted with a password stored in the passwords database.
-
-In case the instance you're deploying on is operated by the Core team, you should use the `OTA-bot` SSH private key instead of your personal one. You can thus run any of the commands with the `--private-key` option, passing it the path to the bot SSH private key. This key can be found in the passwords database.
-
-### Commands examples
-
-- Check deployment without actually applying changes for the `dating` instance:
-
-```
-ansible-playbook --inventory ops/inventories/production.yml ops/app.yml --limit dating --check --diff
-```
-
-- Update the Open Terms Archive application only on the `dating` instance, without applying changes to the infrastructure:
-
-```
-ansible-playbook --inventory ops/inventories/production.yml ops/app.yml --limit dating --tag update
-```
-
-- Update services declarations only on the `france` instance:
-
-```
-ansible-playbook --inventory ops/inventories/production.yml ops/app.yml --limit france --tag update-declarations
-```
-
-- Stop the Open Terms Archive application only on the `france` instance:
-
-```
-ansible-playbook --inventory ops/inventories/production.yml ops/app.yml --limit france --tag stop
-```
-
-- Update the infrastructure and the Open Terms Archive application on all servers:
-
-```
-ansible-playbook --inventory ops/inventories/production.yml ops/site.yml
-```
-
-## Set up a new instance
-
-### Provision a server
-
-#### With [OVH Horizon](https://horizon.cloud.ovh.net/project/instances/)
-
-Click on the `Launch Instance` button. Then fill in at least the following fields:
-
-- `Instance name`.
-- `Source`. Suggested: `Debian 11`.
-- `Flavor`. Suggested: `b-7-flex`.
-- `Key pair`. Suggested: Your own personal SSH key, to allow you to connect to the freshly created server.
-
-#### Recommended specs
-
-The following setup is sufficient to track 20 services:
-
-- 1 vCore @ 1.8GHz
-- 2 GB RAM
-- 1 MBps bandwidth
-- 20 GB disk space
-
-The major factor for performance is bandwidth.
-
-Disk space is used up linearily with time as the archive grows. The number of services, their frequency of change and the chosen storage mechanism will all influence the speed at which disk space is used. You can start with 20GB but will have to consider expansion in the future. You should be safe for a longer time period with 100GB.
-
-We suggest using a dedicated attached volume for storage, independently from the main VM drive, so that you can more easily upgrade or format it.
-
-### Define host
-
-Add an entry to the production inventory file `ops/inventories/production.yml` for the created host with the server address and proper variables.
-
-The host name can not contain dashes. Use snake_case.
-
-### Configure instance
-
-Create a JSON file in the `config` folder with the name of the instance.
-
-### Create repositories
-
-Create the `snapshot` and `version` repositories, with:
-
-- A `main` branch.
-- The `main` branch should be the default branch.
-- At least one commit on this branch with some content (`README.md` and `LICENSE`).
-
-Templates are provided to that end, for [declarations](https://github.com/OpenTermsArchive/template-declarations/), [snapshots](https://github.com/OpenTermsArchive/template-snapshots/) and [versions](https://github.com/OpenTermsArchive/template-versions/).
-
-### Set up permissions
-
-The @OTA-Bot GitHub user should have write access to all three (declarations, snapshots, versions) repositories, so it can publish data, create issues, and publish dataset releases.
-
-Each instance should have a responsible entity, which we currently model as a [“team” in the @OpenTermsArchive](https://github.com/orgs/OpenTermsArchive/teams) GitHub organisation. Each team has write access to the three repositories, and @OTA-Bot should be added to that team along with the human maintainers.
-
-## Optimise performance
-
-### MongoDB
-
-If you use MongoDB as storage, hosting the database on an XFS-formatted volume significantly improves performance.
-
-The following instructions assume [OVH Horizon](https://horizon.cloud.ovh.net/project/instances/) for volume creation, but can be adapted for any cloud provider.
-
-#### Mounting
-
-- Create a volume with the highest speed possible.
-- Attach the volume to the server that runs your Open Terms Archive instance.
-- On the machine, check what is your volume with `lsblk` (it should be one with no partition).
-- Then use `sudo fdisk /dev/sd$N` (where `$N` is the identifier of the volume) and answer `n`, `p`, `1`, `w`.
-- Install XFS utilities `sudo apt-get install xfsprogs`
-- Format the disk to XFS: `sudo mkfs.xfs -f /dev/sd$N1`/
-- Finally, create a folder (for example in `/mnt`) and mount the volume in it: `sudo mount -t auto /dev/sd$N1 /mnt/disk`.
-
-#### Unmounting
-
-To remove a volume:
-
-- Unmount it with `sudo umount /mnt/disk`.
-- Unattach it from the Horizon console.
-- Remove the volume from the Horizon console.

package/ops/app.yml

@@ -1,5 +0,0 @@
----
-- name: Set up Open Terms Archive app and databases
-  hosts: all
-  roles:
-    - ota

package/ops/infra.yml

@@ -1,6 +0,0 @@
----
-- name: Set up Open Terms Archive infrastructure
-  hosts: all
-  become: yes
-  roles:
-    - infra

package/ops/inventories/dev.yml

@@ -1,7 +0,0 @@
-vagrant:
-  hosts:
-    127.0.0.1:
-      ansible_user: vagrant
-      ansible_port: 2222
-      ansible_python_interpreter: /usr/bin/python3
-      ansible_ssh_private_key_file: ~/.ssh/ota-vagrant

package/ops/inventories/production.yml

@@ -1,27 +0,0 @@
-contrib:
-  hosts:
-    198.244.153.104:
-      ed25519_fingerprint: AAAAC3NzaC1lZDI1NTE5AAAAIITN8hTCst7+6mHNzeo465crCZwHrc/SzUL1410mb9Lv
-dating:
-  hosts:
-    vps-99ae1d89.vps.ovh.net:
-      ed25519_fingerprint: AAAAC3NzaC1lZDI1NTE5AAAAIClFdaZhaXFmxdQI+rNSOsZaSlrgPlK9UzyGvi66u88V
-france:
-  hosts:
-    198.244.142.9:
-      ed25519_fingerprint: AAAAC3NzaC1lZDI1NTE5AAAAIKH7P9SCnnSiVOhGMNvHIjWw5+3TYlmgmTK45Y9d1aCu
-pga:
-  hosts:
-    134.102.58.70:
-      ansible_user: pga
-      ed25519_fingerprint: AAAAC3NzaC1lZDI1NTE5AAAAIDmKHW4LMOEIxnBHkdNzwvSrzjmfhQkx5n2lFtJdraOy
-p2b_compliance:
-  hosts:
-    vps-463f0baf.vps.ovh.net:
-      ansible_user: ota
-      ed25519_fingerprint: AAAAC3NzaC1lZDI1NTE5AAAAIDOrkEl2aR2gJe0XmLy4j+0/51G/kAlkupfU4S2Qv0dJ
-      config_file_name: p2b-compliance
-
-all:
-  vars:
-    ansible_user: debian

package/ops/roles/infra/defaults/main.yml

@@ -1,2 +0,0 @@
-instance_name: '{{ group_names[0] }}'
-config_file_name: '{{ instance_name }}'

package/ops/roles/infra/files/.gitconfig

@@ -1,3 +0,0 @@
-[user]
-	email = bot@opentermsarchive.org
-	name = Open Terms Archive Bot