Migration python 3

Supporter exprès 3.3 ne me semble pas une idée géniale, perso. La version courante de Python 3 est 3.4, alors si on passe à Python 3, on passe à Python 3.4 et basta. Ça ne veut pas dire que le site ne tournera pas sur 3.3 (parce qu'avec une codebase fraîchement portée de Python 2 si vous arrivez à coller des éléments nouveaux de Python 3.4 non-supportés dans 3.3 dans le code, je veux bien vous tirer mon chapeau), mais juste qu'à mon avis ça ne vaut pas le coup de s'en inquiéter.

parce qu'avec une codebase fraîchement portée de Python 2 si vous arrivez à coller des éléments nouveaux de Python 3.4 non-supportés dans 3.3 dans le code, je veux bien vous tirer mon chapeau

Suffit de placer une énumération si il y a que ça pour t’impressionner

Suffit de placer une énumération si il y a que ça pour t’impressionner

mmmmh

parce qu'avec une codebase fraîchement portée de Python 2 si vous arrivez à coller des éléments nouveaux de Python 3.4 non-supportés dans 3.3 dans le code, je veux bien vous tirer mon chapeau)

challenge accepted

Répète après moi #ilovezep12

C'est pas un challenge, hein, c'est juste qu'il y a très peu de chances pour que ça arrive spontanément à moins de le faire exprès. En gros, je vois aucun cas où on pourrait ne pas avoir le choix d'utiliser une des nouveautés de python 3.4 : ce sont des trucs mineurs et il faudrait vraiment ne pas avoir de bol pour que le résultat ne soit pas compatible 3.3.

Je sais bien, j'ai dis en gros la même chose que toi plus tôt, supporter python 3.3 n'a aucun interêt. Python 3.3 est tellement vieux que même Debian passe bientot à la 3.4. Et tout le monde sais que Debian ne sont pas les plus rapides…

Debian 8 est maintenant sorti.

Étant donné que l'on va y passer avec la migration vers python3, je me pose la fameuse question : Est-ce que l'on restera sur une BD Mysql ? Ou passerons nous sur MariaDB/PostgreSQL ?

J'ai besoin de savoir pour faire évoluer la documentation de ma Pull Request si besoin.

En parallèle, on peut voir que debian 8 vient avec Nagios (la crème de la crème de la supervision opensource), est-ce que ça vaut le coup de garder munin ?

Est ce qui ne serait pas pertinent de faire ça étape par étape ? Le passage à Python 3 est déjà assez casse gueule comme ça, peut être que les trucs annexes (mysql vs posgresql vs mariaDb, Nagios vs munin) pourraient se faire dans une autre release, après ?

Pour commencer, je suis d'accord avec Kje : le passage à Python 3 étant déjà assez casse gueule, autant limiter la surface d'échecs possibles et limiter les modifications au minimum (python 3 + le système de base pour en profiter sereinement, c'est déjà pas mal !)

Cela dit, parce que le sujet va forcément venir sur le tapis :

Étant donné que l'on va y passer avec la migration vers python3, je me pose la fameuse question : Est-ce que l'on restera sur une BD Mysql ? Ou passerons nous sur MariaDB/PostgreSQL ?

Vu que MariaDB est sensé être compatible, on peut imaginer une migration assez facilement, ce qui n'empêche pas de réfléchir sérieusement à l'impact qu'une telle migration peut avoir (en terme de migration de données et d'administration en particulier).

Quant à PostgreSQL, il faudrait une raison en béton armé pour repasser dessus. Concrètement, ça veut dire :

1. Montrer qu'on a les compétences en administration dans l'équipe pour gérer une telle base. Pour rappel, c'est ce manque qui a fait qu'on a lancé les tests pour passer à MySQL à l'origine.
2. La preuve, tests de charge pertinents à l'appui, qu'on conserve des performances au moins identiques avec PostgreSQL. Des tests réels sur l'application ZdS sont indispensables, tout test autre (et plus encore toute supposition basée sur des vieilles versions de MySQL et PostgreSQL) sera impitoyablement et irrémédiablement ignoré.

En parallèle, on peut voir que debian 8 vient avec Nagios (la crème de la crème de la supervision opensource), est-ce que ça vaut le coup de garder munin ?

Ça dépend, qu'est-ce que ça implique en termes d'infrastructure et d'administration ?

Arguments systématiquement refusés :

• "La licence est plus mieux" (souvent avancé dans le débat MariaDB vs MySQL). Si la licence est assez libre pour que le logiciel soit dans les paquets Debian (qui est très chiant sur ce point), alors elle est assez bonne pour Zeste de Savoir.
• "On dit que …". Les "On dit" ne s'appliquent pas forcément au cas de ZdS – ni même ne sont forcément pertinents. Exemple : ZdS fait beaucoup de requêtes SQL très simples. Conséquence : on passe très peu de temps dans la BDD elle-même mais beaucoup à la gérer en Python. Donc, une BDD moyenne avec un excellent driver serait bien plus intéressante pour le projet qu'une excellente BDD avec un driver moyen.
• "Cette technologie est expérimentale mais…" : On parle de production. On ne met pas de l'expérimental en production. D'autant plus que toute l'équipe qui gère le site est bénévole et donc a autre chose à faire et donc n'a pas le temps de réparer la production cassée parce qu'un module expérimental a explosé.

Je soulève ces points parce que ce sont de gros changements d'Infra, et quitte à installer un nouveau serveur depuis zero, autant ne le faire qu'une seule fois.

Pour ce qui est de Nagios, je peux faire (peut être pas tout de suite) un résumé en quelques points de "pourquoi c'est mieux pour zds". En attendant, l'idée est surtout de savoir s'il y a d'autres changements d'Infra envisagés avec le passage à debian8 ?

Ni le passage à MariaDB, ni le passage à PostgreSQL, ni le passage à Nagios ne nécessite d'installer un nouveau serveur depuis 0.

Je suis l'ancien DTC et je plussoie de toute mes forces l'avant-dernier post de SpaceFox.

PS : "Faire les gros changements en une seule fois", ça peut s'entendre quand on veut déployer une update majeure pour un client et qu'on ne veut pas y retoucher avant plusieurs mois/années.

C'est pas que ce soit une mauvaise approche, au contraire, seulement c'est le genre de migration qui se prépare au millimètre avant de la faire si on ne veut pas que ce soit une grosse séance de plug n'pray. Je ne pense pas que l'équipe technique actuelle ait les ressources de préparer ce genre de migration, à moins que vous ne comptiez la faire dans 6 mois, ce qui n'est pas compatible avec "on merge le passage à Python 3 ASAP".

Pour rappel, le passage à Python 3 est déjà tellement délicat que vous envisagez déjà ne merger aucune PEP en même temps. Alors changer des gros bouts d'infra ?

Ce n'est pas ce que j'ai dis . Le passage a python3 non plus ne nécessite pas d'installer un nouveau serveur depuis zéro. Mais étant donné que ça demande de la grosse configuration on le fait au moment du passage sur les nouveaux serveurs

Le passage a python3 non plus ne nécessite pas d'installer un nouveau serveur depuis zéro.

En fait, si, c'est pour ça qu'on le fait. Pourquoi ? Parce que pour avoir une version récente de Python 3, on a le choix entre :

• Rester en Debian 7 et installer une version de Python 3 non supportée par Debian,
• Passer en Debian 8 (ou toute autre distribution concurrente qui possède Python 3 en standard en fait) et utiliser la version de Pyton 3 fournie dans les packages.

Comme on veut éviter qu'un composant aussi sensible soit géré à la main pour sa maintenance et sa sécurité, on se retrouve avec une réinstallation d'OS inévitable. Les autres éléments cités sont présents dans les paquetages de Debian 8 et donc ne nécessitent pas une réinstallation complète pour les utiliser.

PS : pour être tout à fait exact, on pourrait migrer notre Debian 7 actuelle vers une Debian 8, ce qui serait la solution idéale si elle n'avait pas 3 inconvénients majeurs :

1. Il faudrait que notre hébergeur le permette, ce qui n'est pas gagné.
2. L'installation actuelle est franchement bancale, dans tous les cas on devra réinstaller un serveur propre un jour.
3. Notre hébergeur actuel ne nous donne pas entièrement satisfaction et donc on devra obligatoirement réinstaller le serveur le jour où on changera (y compris si on passe sur du OVH VPS Cloud).

J'ai regardé pour Nagios. Non seulement la v4 ne semble pas disponible dans Debian (la 3 l'était déjà), mais en plus ça a l'air d'être une horreur absolue à installer et configurer

Je me permet de remonter ce sujet vieux de plus d'un an déjà. Si j'ai bien compris l'issue, les dépendances fonctionnent en Python 3 et on a du 3.4.2 sur la prod (fin 2015), donc peut-être même du 3.5 à l'heure actuelle.

Je veux bien avancer sur ce sujet et faire des tests pour aider.

J'ai une POC sous le coude qui arrive en PR quand la ZEP-13 est mergée

On en est ou?

Sommes-nous encore en python 2 ou est-on passé avec python 3?

Question Bonus : Si nous sommes encore avec python 2, que manque-t-il (reste-t-il à faire) pour passer à python 3?