Modules Go

Organisation des modules Go du projet etcd

Référence

Le projet etcd (à partir de la version 3.5) est organisé en plusieurs modules golang hébergés dans un référentiel unique .

Les modules suivants sont disponibles :

go.etcd.io/etcd/api/v3 - contient les définitions d’API (protos et bibliothèques générées à partir de protos) qui définissent le protocole de communication entre les clients et le serveur etcd.
go.etcd.io/etcd/pkg/v3 - ensemble de packages d’utilitaires utilisés par etcd sans être spécifiques à etcd lui-même. Un package doit être placé ici uniquement s’il pourrait éventuellement être déplacé vers son propre dépôt à l’avenir. Évitez d’ajouter ici du code qui a de nombreux dépendances, car celles-ci deviendraient automatiquement des dépendances de la bibliothèque cliente (que nous souhaitons garder légère).
go.etcd.io/etcd/client/v3 - bibliothèque cliente utilisée pour contacter etcd sur le réseau (grpc). Recommandée pour toute utilisation nouvelle d’etcd.
go.etcd.io/etcd/client/v2 - bibliothèque cliente héritée utilisée pour contacter etcd via le protocole HTTP. Dépréciée. Tout usage nouveau doit dépendre de la bibliothèque /v3.
go.etcd.io/etcd/raft/v3 - implémentation du protocole de consensus distribué. Doit ne pas contenir de code spécifique à etcd.
go.etcd.io/etcd/server/v3 - implémentation etcd. Le code de ce package est interne à etcd et ne doit pas être utilisé par des projets externes. La structure du package et l’API peuvent évoluer au sein des versions mineures.
go.etcd.io/etcd/etcdctl/v3 - un outil en ligne de commande permettant d’accéder à etcd et de le gérer.
go.etcd.io/etcd/tests/v3 - un module qui contient tous les tests d’intégration de etcd. Remarque : Tous les tests unitaires (rapides et n’exigeant pas de dépendances entre modules) doivent être conservés dans les modules locaux au code testé.
go.etcd.io/bbolt - implémentation d’un arbre b persistant. Hébergé dans un dépôt séparé : https://github.com/etcd-io/bbolt .

Opérations

Tous les modules etcd doivent être publiés en versions identiques, par exemple : go.etcd.io/etcd/client/v3@v3.5.10 doit dépendre de go.etcd.io/etcd/api/v3@v3.5.10.

La mise à jour cohérente des versions peut être effectuée à l’aide de :

% DRY_RUN=false TARGET_VERSION="v3.5.10" ./scripts/release_mod.sh update_versions

Les modules publiés doivent être étiquetés conformément aux règles https://golang.org/ref/mod#vcs-version , c’est-à-dire que chaque module doit recevoir sa propre étiquette. La mise en étiquette peut être effectuée à l’aide de :
```
% DRY_RUN=false REMOTE_REPO="origin" ./scripts/release_mod.sh push_mod_tags
```
Tous les modules etcd doivent dépendre des mêmes versions des dépendances sous-jacentes. Cela peut être vérifié à l’aide de :
```
% PASSES="dep" ./test.sh
```
Les fichiers go.mod ne doivent pas contenir de dépendances non utilisées et doivent respecter le format go mod tidy. Cette vérification est effectuée par :
```
% PASSES="mod_tidy" ./test.sh
```
Pour déclencher des actions sur tous les modules (par exemple, formater automatiquement tous les fichiers), veuillez use/expand exécuter le script suivant :
```
% ./scripts/fix.sh
```

Avenir

En tant qu’indicateur principal, nous souhaitons évaluer les modules etcd selon le modèle suivant :

Cela suppose :

Séparation de etcdmigrate/etcdadm à partir de la binaire etcdctl. Grâce à cela, etcdctl deviendrait clairement un wrapper en ligne de commande autour de l’API client réseau, tandis que etcdmigrate/etcdadm prendrait en charge les opérations physiques directes sur les fichiers de stockage etcd.
Séparation de etcd-proxy à partir de la binaire ./etcd, car elle contient un code plus expérimental et donc des risques et des dépendances supplémentaires.
Dépréciation du support du protocole v2.