Project

General

Profile

Fonctionnalité #22092

Stockage S3

Added by Cyril VAZQUEZ 3 months ago. Updated about 1 month ago.

Status:
A tester (S)
Priority:
1-Majeur
Assignee:
Target version:
Start date:
09/14/2022
Due date:
09/28/2022
Tags RM:

Description

Développement du connecteur de stockage S3 pour usage comme entrepôt de données au sein de grappe de stockages.

History

#1 Updated by Cyril VAZQUEZ 3 months ago

Impacts

Ajout d'un connecteur dans dependency/repository/Adapter

Modification du code responsable du calcul de la localisation de stockage pour supprimer l'adhérence aux systèmes de fichiers.
Dans la version actuelle le fonctionnement est le suivant :

Au dépôt
- calcul d'un chemin de stockage selon le masque de configuration et les variables de contexte (archive, message, date...)
- ouverture d'un conteneur de stockage (création ou ré-ouverture existant) par appel à la chaîne digitalResource->cluster->repository
- dépôt effectif par appel à la chaîne digitalResource->cluster->repository
- inscription du conteneur de stockage dans les métadonnées de l'archive

On a donc un double problème
- de responsabilité / répartition de code (car c'est le bundle recordsManagement qui produit le chemin de stockage passé aux composants responsables du stockage effectif)
- de modèle de données car le chemin est unique alors que le stockage peut être multiple, et incompatible a priori avec deux systèmes utilisant un adressage différent

#2 Updated by Cyril VAZQUEZ 3 months ago

Evolution sans impact :

Le chemin de stockage interne conservé dans l'objet archive reste une information agnostique du système de stockage (info métier).

Chaque connecteur de stockage est responsable de son interprétation pour fournir une localisation dans son propre schéma d'adressage interne.
- Pour fileSystem, aucune modification
- pour S3, configuration de la profondeur du chemin (en nombre de noms) qui désignent le bucket, la suite étant la clé de l'objet

Exemple :
configuration : {instance}/{originatorOwnerOrgId}/{archivalProfileReference}/{date(Y)}/{date(M)}/{date(d)}

chemin résolu archive : maarchRM/123456789/FACTURE/2022/09/15/archiveId

chemin filesystem : maarchRM/123456789/FACTURE/2022/09/15/archiveId/resId

Localisation S3
- bucket : maarchRM.123456789
- key : /FACTURE/2022/09/15/archiveId/resId

#3 Updated by Cyril VAZQUEZ 3 months ago

Début de connecteur avec gestion des chemins de stockage reçus de recordsManagement.archive pour prise en compte de 2 parties
- bucket (conteneur)
- key (objet)

Le nombre de parties du chemin à prendre en compte est défini dans l'option de paramétrage du repository bucketPathSteps

Correction d'un bug mineur sur l'écran de définition des paramètres.
Correction d'un bug mineur dans le contrôleur digitalResource.repository dans la fonction qui traite les paramètres.

#4 Updated by Cyril VAZQUEZ 3 months ago

  • File S3 repository.png added

#5 Updated by Cyril VAZQUEZ 3 months ago

  • File Capture.PNG added

#6 Updated by Cyril VAZQUEZ 3 months ago

  • File deleted (S3 repository.png)

#7 Updated by Cyril VAZQUEZ 3 months ago

  • File S3 repository.png added

Prérequis

Installer le SDK https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/getting-started_installation.html

Configurer le support (voir image)
* chemin vers le sdk
* identifiant et secret pour authentification
* nombre d'éléments de chemin pour le nom du bucket

#8 Updated by Cyril VAZQUEZ 3 months ago

  • File deleted (Capture.PNG)

#9 Updated by Cyril VAZQUEZ 2 months ago

  • File Capture.PNG added

Edit : La cible est le service OVH ObjectStorage.

Le service utilise une interface Swift.
L'API S3 n'est présenté que via un SDK python en ligne de commande, aucun SDK PHP disponible.
L'adaptation du SDK AWS représenterait une charge trop importante.

Intégration d'un client Swift via le SDK OpenStack https://github.com/php-opencloud/openstack

Paramètres du repository cf image 2.

#10 Updated by Cyril VAZQUEZ 2 months ago

  • File deleted (Capture.PNG)

#12 Updated by Cyril VAZQUEZ 2 months ago

Modification du connecteur S3 pour prise en compte des spécificités du stockage OVH et gestion par le client.

Paramètres :

  • version : version de l'API (latest, v3, v4...)
  • sdk : chemin vers le SDK AWS (où se trouve le fichier autoloader.php)
  • region : région (bhs pour tests OVH)
  • key : clé d'identification de l'utilsiateur
  • secret : secret pour identification
  • bucket : soit le nom du bucket à utiliser pour le repo en dur, soit un entier définissant la profondeur du chemin de stockage à utiliser pour déterminer le nom dynamiquement

Tests réalisés :
* versement
* dépôt direct via gestion
* destruction directe via gestion
* lecture
* contrôle d'intégrité

A faire :
* profilage
* élimination
* voir si le bucket peut être intégré au endpoint comme uri du service

#13 Updated by Cyril VAZQUEZ 2 months ago

  • File deleted (S3 repository.png)

#14 Updated by Cyril VAZQUEZ about 1 month ago

  • Status changed from A traiter to A tester (S)

#15 Updated by Cyril VAZQUEZ about 1 month ago

Erreur lors de l'ajout d'un support dans une grappe existante.
La fonction de lecture cherche les adresses pour tous les supports et lève une exception si non trouvée.

A faire : prévoir le cas d'un nouveau support pour migration.

#16 Updated by Cyril VAZQUEZ about 1 month ago

Modifications apportées sur plusieurs fonctions :

DigitalResource

  • contents()
  • metadata()
  • info()
  • delete()

cluster:

  • retrieveRessource()

Test d'existence de l'adresse sur le support, pour toute itération dans les supports d'une grappe

Modification de retrieveRessource() pour lever une exception lorsqu'on sort de la fonction sans avoir retourné de pointeur de données (donc aucun support ne contient les données).

Also available in: Atom PDF