Spécification initiale#

Contexte#

Gérer les publications & co pour les configurations de type ITINERARY-ISOCURVE

Description#

Les tâches de cet agents de publication sont de:

  • Gérer les publication / dépublication / synchronisation en provenance de l’entrepôt vers du ITINERARY-ISOCURVE

  • Alimenter son service lors du démarrage de celui-ci

Points d’attention#

Le pot commun IGNGPF-319 reprend les opérations génériques à implémenter, ainsi que les éléments du message principaux : seul le détails du type_infos est repris ici.

Régles de gestion#

  • Le type de l’offre doit être ITINERARY-ISOCURVE

  • Le type_infos du message de publication est celui indiqué dans la configuration, à quelques exceptions (voir ci après)

  • used_data/stored_data va contenir la “vraie” structure de la donnée stockée

stored_data*    {
    _id*    string
    name*    string
    type*    stringEnum:  --> GRAPHE-DB, GRAPH-OSRM ou GRAPH-VALHALLA
    srs    string
    extent    { x1 x2 y1 y2}
    type_infos    {
    --> Voir les tickets IGNGPF-1107, IGNGPF-1108, IGNGPF-1109
    }
    storage*    {
    _id*    string
    name*    string
    type*    string
    type_infos*    {  
        --> Voir ci-dessous
    }
}

  • used_data/stored_data/storage va contenir la “vraie” structure du stockage avec un type_infos qui dépend du type de stockage : S3 ou POSTGRESQL-ROUTING

  • l’agent de publication doit :

    • Utiliser les mécanisme commun de pyroger pour gérer les cas de démarrage et la reception des messages à sa destination, en appliquant les principes de publication / dépublication / synchronisation spécifique décrits ci-dessous

    • Publication : à partir de la configuration et disponible dans la balise type_infos, l’agent de publication va:

      • Créer les fichiers de configurations road2 via l’utilitaire road2config disponible via le paquet python route-graph-generator

      • Copier ces fichiers dans le répertoire des resources et sources du service road2

        • Dans le cas des graphes OSRM et Valhalla, les fichiers disponibles dans le stockage objet doivent être copiés sur un volume partagé avec le endpoint

          • Afin d’éviter de recopier plusieurs fois les mêmes données, on vérifie le hash md5 de la stored data sur le S3. S’il est identique à celui présent sur le endpoint, le téléchargement n’est pas effectué et l’on garde la donnée disponible

          • Le fichier de hash md5 de la stored data sur le S3 est copié sur le endpoint

          • Attention : il s’agit d’une pratique qui ne correspond pas au comportement attendu dans l’entrepot. Cependant les utilitaires OSRM et Valhalla utilisés pour faire le calcul d’itinéraire ne supportent pas le stockage objet.

        • Récupérer le nom du service associé au endpoint road2 : requete sur route /admin/1.0.0/services

        • Demander le redémarrage du service road2 via une requête sur la route /admin/services/:service/restart

    • Dépublication : à partir de la configuration et disponible dans la balise type_infos, l’agent de publication va:

      • Récupérer les sources Road2 à supprimer depuis le layername de la configuration à dépublier, dans le fichier .resource

      • Supprimer le fichier de resource associé à la configuration

      • Récupérér l’ensemble des sources encore utilisées par Road2 depuis tout les fichiers de resource

      • Supprimer les sources de la resource à dépublier qui ne sont pas utilisées:

        • Suppression des répertoires indiqués dans la balise storage:

          • répertoire des graphes pour OSRM

          • répertoire des tuiles pour Valhalla

          • fichier de configuration de base pour PGR

        • Suppression du fichier .source -Récupérer le nom du service associé au endpoint road2 : requete sur route /admin/1.0.0/services

        • Demander le redémarrage du service road2 via une requête sur la route /admin/services/:service/restart

    • Synchronisation: à partir de la configuration et disponible dans la balise type_infos, l’agent de publication va:

      • Récupérer les sources Road2 utilisées par la configuration de publication actuelle depuis la définition de la resource à modifier dans le fichier .resource

      • Effectuer une nouvelle publication avec la nouvelle configuration. Si les données sont déjà disponibles, elles ne seront pas retélécharger.

      • Récupérér l’ensemble des sources encore utilisées par Road2 depuis tout les fichiers de resource

      • Supprimer les sources de la resource initiale (avant modification) qui ne sont pas utilisées:

        • Suppression des répertoires indiqués dans la balise storage:

          • répertoire des graphes pour OSRM

          • répertoire des tuiles pour Valhalla

          • fichier de configuration de base pour PGR

        • Suppression du fichier .source

    • Lors du redémarrage du service, si la requête retourne une erreur, la publication ou synchronisation doit :

      • retourner un statut ERR

      • supprimer les fichiers copiés sur le endpoint (resource, sources, graphes ou configuration de base)

      • un restart du service est effectué pour que les autres configurations restent disponibles

  • Cas d’erreurs :

    • les graphes copiés ne peuvent pas être utilisés par Road2 lors du redémarrage du service

    • la base de données pgrouting n’est pas accessible

    • la configuration indiquée n’est pas supportée par Road2

    • les CRS indiqués ne sont pas supportés par Road2 (dans les stored data ou la configuration des projections de la resource)