Ne pas echouer sur la copie des fichiers des volumes vers le docker
Closed this issue · 6 comments
Lorsque l'entrypoint ecrit des fichiers depuis le volume vers l'instance du docker (par exemple les fichiers) il peut arriver que des fichiers ne soient pas copiables.
Il serait préférable de ne pas planter mais de logguer le fichier en cause:
https://github.com/Polyconseil/grocker/blob/master/bundles/runner/02_entrypoint.py#L155
On a des exemples réels de problèmes avec ça ?
Oui, des fichiers avec de mauvaises perms etaient presents sur un volume.
une sombre histoire de fichier de backup vim (edition a la mano ?)
2015-09-11 15:55 GMT+02:00 Raphaël Barrois notifications@github.com:
On a des exemples réels de problèmes avec ça ?
—
Reply to this email directly or view it on GitHub
#45 (comment).
Benoît CALVEZ
Polyconseil | 26 rue de Berri | 75008 Paris
Est-ce que "planter" n'est pas la meilleure solution ? Si le fichier en question contient des informations importantes mais qu'il n'a pas été déposé avec les bons droits, on lance quand même le SI ?
Dans tous les cas, ça serait bien de récupérer l'exception pour avoir un message plus sympathique pour l'utilisateur.
Suggestion : on ne charge que les fichiers *.ini, on crashe s'ils sont faux.
On ignore les fichiers cachés ; on met un avertissement sur les noms inconnus ?
En fait, on ne charge déjà que les fichiers *.ini. Le problème est lors de la copie des fichiers dans le dossier où les fichiers de configuration venant de l'hôte et ceux construit par Grocker sont regroupés.
On pourrait faire un cas particulier pour les fichiers *.ini, mais ça suppose que l'on considère comme quelque chose de normal la présence de fichiers non lisibles dans les dossiers de configuration...
Ce problème n'est survenu qu'une fois et la nouvelle architecture s'oriente vers l'utilisation d'un discovery service. Si le problème se reproduit on ouvrira une issue sur Grocker-BlueDjango