Chapitre 3
Maintenance
Cette section détaille les procédures d’exploitation courantes.
Sous-sections de Maintenance
Mise à jour du modèle de données serveur
Un modèle de données n’est pas figé dans le temps, il peut évoluer et donc être mis à jour, que ce soit depuis le serveur ou sur un ou plusieurs clients.
A chaque modification du modèle de données sur le serveur, sa nouvelle version est propagée aux clients avec ses données “publiques” : chaque type de données est inclus, avec sa clé primaire, la liste de ses attributs et la liste de ses attributs secrets. Des événements consécutifs sont ensuite émis.
Ajouter un attribut à un type de données existant
- 👱 Ajouter l’attribut au modèle de données serveur, redémarrer le serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Emission d’événements “modified” pour les entrées concernées, avec l’attribut ajouté et sa valeur
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma. Traitement des événements “modified” entrants : comme l’attribut n’est pas encore déclaré dans leurs modèles de données, sa valeur est ignorée mais stockée dans le cache complet
- 👱 Ajouter l’attribut aux modèles de données clients, redémarrer les clients
- 💻 Traitement des mises à jour du modèle de données local par les clients : génération et traitement des événements locaux “modified” depuis le cache complet
ou
- 👱 Ajouter l’attribut aux modèles de données clients afin qu’ils puissent le traiter lorsqu’il sera ajouté au modèle de données serveur, redémarrer les clients : ⚠️ avertissement du modèle de données “remote attributes don’t exist in current Dataschema”
- 👱 Ajouter l’attribut au modèle de données serveur, redémarrer le serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Émission d’événements “modified” pour les entrées concernées, avec l’attribut ajouté et sa valeur
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma. ✅ Plus d’avertissement de modèle de données. Traitement des événements “modified” entrants
Supprimer un attribut d’un type de données
- 👱 Supprimer l’attribut des modèles de données clients, redémarrer les clients
- 💻 Traitement des mises à jour du modèle de données local par les clients : génération et traitement des événements locaux “modified” consécutifs
- 👱 Supprimer l’attribut du modèle de données serveur, redémarrer le serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Émission d’événements “modified” pour les entrées concernées, avec l’attribut supprimé. Ils seront ignorés par les clients
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma
ou
- 👱 Supprimer l’attribut du modèle de données serveur, redémarrer le serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Émission d’événements “modified” pour les entrées concernées, avec l’attribut supprimé
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma. ⚠️ avertissement du modèle de données “remote attributes don’t exist in current Dataschema”. Traitement des événements “modified” entrants
- 👱 Supprimer l’attribut des modèles de données clients, redémarrer les clients: ✅ Plus d’avertissement de modèle de données
Modifier la valeur d’un attribut (en changeant son filtre Jinja, ou son attribut distant de la source de données)
- 👱 Modifier l’attribut dans le modèle de données serveur, redémarrer le serveur
- 💻 Émission d’événements “modified” pour les entrées concernées, avec les nouvelles valeurs de l’attribut modifié
- 💻 Traitement des événements “modified” entrants
Ajouter un attribut existant d’un type de données à secrets_attrs
- 👱 Modifier secrets_attrs dans le modèle de données serveur, redémarrer le serveur
- 💻 Purge de l’attribut dans le cache du serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Émission d’événements “modified” pour les entrées concernées, avec l’attribut ajouté et ses valeurs
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma, purge de l’attribut dans leur cache
- 💻 Traitement des événements “modified” entrants
Supprimer un attribut existant d’un type de données de secrets_attrs
- 👱 Modifier secrets_attrs in modèle de données serveur, redémarrer le serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Émission d’événements “modified” pour les entrées concernées, avec l’attribut ajouté et ses valeurs
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma
- 💻 Traitement des événements “modified” entrants
Ajouter un nouveau type de données
- 👱 Ajouter le type de données au modèle de données serveur, redémarrer le serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Émission d’événements “added” pour chaque entrée du type de données ajouté
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma. Traitement des événements “added” entrants : comme le type de données n’est pas encore déclaré dans leur modèle de données, ses entrées sont ignorées mais stockées dans le cache complet
- 👱 Ajouter le type de données aux modèles de données client, redémarrer les clients
- 💻 Traitement des mises à jour du modèle de données local par les clients : génération et traitement des événements locaux “added” depuis le cache complet
ou
- 👱 Ajouter le type de données aux modèles de données client afin qu’ils puissent le traiter lorsqu’il sera ajouté au modèle de données serveur, redémarrer les clients : ⚠️ avertissement du modèle de données “remote types don’t exist in current Dataschema”
- 👱 Ajouter le type de données au modèle de données serveur, redémarrer le serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Émission d’événements “added” pour chaque entrée du type de données ajouté
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma. ✅ Plus d’avertissement de modèle de données. Traitement des événements “added” entrants
Supprimer un type de données existant
- 👱 Supprimer le type de données dans les modèles de données client, redémarrer les clients
- 💻 Traitement des mises à jour du modèle de données local par les clients : génération et traitement des événements locaux “removed” consécutifs
- 💻 Purge des fichiers de cache locaux du type de données supprimé
- 👱 Supprimer le type de données dans le modèle de données serveur, redémarrer le serveur
- 💻 Émission d’événements “removed” pour chaque entrée du type de données supprimé
- 💻 Purge des fichiers de cache du type de données supprimé
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Traitement des événements “removed” entrants par les clients : tous sont ignorés
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma
- 💻 Purge des fichiers de cache distants du type de données supprimé
ou
- 👱 Supprimer le type de données dans le modèle de données serveur, redémarrer le serveur
- 💻 Émission d’événements “removed” pour chaque entrée du type de données supprimé
- 💻 Purge des fichiers de cache du type de données supprimé
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Traitement des événements “removed” entrants par les clients
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma. ⚠️ avertissement du modèle de données “remote types don’t exist in current Dataschema”
- 💻 Purge des fichiers de cache distants du type de données supprimé
- 👱 Supprimer le type de données dans les modèles de données client, redémarrer les clients: ✅ Plus d’avertissement de modèle de données
- 💻 Purge des fichiers de cache locaux du type de données supprimé
Modifier l’attribut de clé primaire d’un type de données
DANGER
Il s’agit de la mise à jour du modèle de données la plus risquée, car il peut y avoir des liens entre les types de données, utilisant des clés primaires comme clés étrangères. Cela signifie que vous devrez mettre à jour tous les types de données en une fois, sans rien manquer.
Vous devriez vraiment envisager d’effectuer cette mise à jour dans un environnement de test avant de la faire en production, car si quelque chose échoue, vos clients pourraient être définitivement compromis.
Prérequis
Les attributs à utiliser comme nouvelle clé primaire doivent déjà exister dans votre modèle de données serveur, et leurs valeurs doivent déjà avoir été propagées et exister dans le cache des clients.
La rétention de la corbeille peut retarder la mise à jour du modèle de données
La nouvelle clé primaire DOIT exister dans chaque entrée de son type de données avant la mise à jour du modèle de données. Si la corbeille est activée sur certains de vos clients, le nouvel attribut de clé primaire peut être absent des entrées qui s’y trouvent.
La manière la plus sûre de gérer cela est d’ajouter l’attribut à votre modèle de données serveur et de retarder le changement de clé primaire d’au moins un jour + autant de jours que la valeur trashbin_retention la plus élevée de tous vos clients.
Si vous ne gérez pas cela de cette manière, le client purgera toutes les entrées en corbeille qui ne contiennent pas la valeur du ou des nouveaux attributs de clé primaire, comme si le délai trashbin_retention était échu.
Mise à jour
- 👱 Mettre à jour tous les types de données dans le modèle de données serveur, redémarrer le serveur
- 💻 Mise à jour des clés primaires modifiées dans les fichiers cache du serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Traitement de l’événement dataschema par les clients : purge des entrées en corbeille auxquelles il manque la nouvelle clé primaire, mise à jour de leurs schémas, mise à jour des clés primaires modifiées dans les fichiers cache et la file d’erreurs
Mise à jour du modèle de données client
Un modèle de données n’est pas figé dans le temps, il peut évoluer et donc être mis à jour, que ce soit depuis le serveur ou sur un ou plusieurs clients.
Chaque fois que le modèle de données est modifié sur un client, le client génère des événements locaux pour propager les modifications de données consécutives sur les cibles. Le client peut notifier des avertissements concernant le modèle de données si certains types de données ou attributs distants sont définis dans son modèle de données mais n’existent pas dans le schéma de données actuel reçu d’hermes-server.
Ajouter un attribut à un type de données existant
- 👱 Ajouter l’attribut aux modèles de données clients, redémarrer les clients
- 💻 Traitement des mises à jour du modèle de données local par les clients : génération et traitement des événements locaux “modified” depuis le cache complet
Supprimer un attribut d’un type de données
- 👱 Supprimer l’attribut des modèles de données clients, redémarrer les clients
- 💻 Traitement des mises à jour du modèle de données local par les clients : génération et traitement des événements locaux “modified” consécutifs
Modifier la valeur d’un attribut (en changeant son filtre Jinja ou son attribut distant de la source de données)
- 👱 Modifier l’attribute dans les modèles de données client, redémarrer les clients
- 💻 Traitement des mises à jour du modèle de données local par les clients : génération et traitement des événements locaux “modified” consécutifs
Ajouter un nouveau type de données
Si son hermesType existe déjà dans le schéma de données
- 👱 Ajouter le type de données aux modèles de données client, redémarrer les clients
- 💻 Traitement des mises à jour du modèle de données local par les clients : génération et traitement des événements locaux “added” depuis le cache complet
Si son hermesType n’existe pas encore dans le schéma de données
- 👱 Ajouter le type de données aux modèles de données client afin qu’ils puissent le traiter lorsqu’il sera ajouté au modèle de données serveur, redémarrer les clients : ⚠️ avertissement du modèle de données “remote types don’t exist in current Dataschema”
- 👱 Ajouter le type de données aux modèles de données serveur, redémarrer le serveur
- 💻 Émission d’un événement dataschema par le serveur
- 💻 Émission d’événements “added” pour chaque entrée du type de données ajouté
- 💻 Traitement de l’événement dataschema par les clients : mise à jour de leur schéma. ✅ Plus d’avertissement de modèle de données. Traitement des événements “added” entrants
Supprimer un type de données existant
- 👱 Supprimer le type de données dans les modèles de données client, redémarrer les clients
- 💻 Traitement des mises à jour du modèle de données local par les clients : génération et traitement des événements locaux “removed” consécutifs
- 💻 Purge des fichiers de cache locaux du type de données supprimé