Migration vers influxdata/influxdb-client-php v3 et adaptation du code dans cmd.class.php

[kwizer15]

Votre demande de fonctionnalité est-elle liée à un problème ? Veuillez le décrire.
Oui, cette demande est liée à un problème de dépendance dans le projet. Initialement, le code dans cmd.class.php était conçu pour fonctionner avec la bibliothèque obsolète "influxdb/influxdb-php": "^1.15", alors que la dépendance spécifiée dans composer.json était "influxdata/influxdb-client-php": "^3". Après analyse, j'ai découvert que ces bibliothèques sont fondamentalement différentes : la version 3 est exclusivement compatible avec InfluxDB2 et utilise un système d'authentification par token, tandis que la version 1.15 est conçue pour InfluxDB1 avec authentification par login/mot de passe.

Décrivez la solution que vous souhaitez
Après une analyse plus approfondie, je propose une approche en deux phases :

1. À court terme : maintenir la dépendance "influxdb/influxdb-php": "^1.15" comme proposé dans la PR Correction de la dépendance InfluxDB dans composer.json pour compatibilité avec le code actuel #3038 pour assurer la stabilité des installations existantes.

2. À moyen terme : développer une solution qui supportera les deux versions d'InfluxDB :

   • Adapter le code dans cmd.class.php pour détecter la version d'InfluxDB utilisée
   • Implémenter les appels API appropriés selon la version détectée
   • Potentiellement développer cette fonctionnalité sous forme de plugin dédié qui offrirait une interface commune

Décrivez les alternatives que vous avez envisagées

1. Migration complète et immédiate vers "influxdata/influxdb-client-php": "^3" : cette option forcerait tous les utilisateurs à migrer vers InfluxDB2, ce qui n'est pas souhaitable pour la continuité du service.

2. Maintenir uniquement la compatibilité avec InfluxDB1 via "influxdb/influxdb-php": "^1.15" indéfiniment : cette option évite un travail immédiat, mais elle maintient une dépendance obsolète, ce qui pourrait poser des problèmes de sécurité ou de compatibilité à l'avenir.

Contexte supplémentaire
La bibliothèque "influxdb/influxdb-php": "^1.15" n'est plus activement maintenue (dernière mise à jour significative en 2018), tandis que "influxdata/influxdb-client-php" est la bibliothèque officielle recommandée par InfluxData pour interagir avec InfluxDB2.

La complexité de cette migration réside dans les différences fondamentales entre les deux versions d'InfluxDB, notamment au niveau des méthodes d'authentification et des API. Une solution progressive permettrait de maintenir la compatibilité avec les installations existantes tout en préparant la voie pour les utilisateurs souhaitant adopter InfluxDB2.

Voir la PR de "revert" vers "influxdb/influxdb-php": "^1.15" #3038

[pifou25]

La PR #3038 c'est donc l'alternative, de rester sur la lib obsolète.
La solution souhaitée est préférable je pense, c'est complexe de faire évoluer la classe pour correspondre à la nouvelle version ?

[kwizer15]

Oui c'est l'alternative, mais c'est surtout pour revenir à quelque chose de fonctionnel. Bien évidement, un correctif du code, testé, serait plus judicieux.
Ca ne doit pas être complexe mais ca nécessiste de faire tourner InfluxDB et de passer dans les 4 ou 5 méthodes concernées pour constater le bon fonctionnement.

[kwizer15]

Suite à une analyse plus approfondie, je constate que la migration vers influxdata/influxdb-client-php v3 présente des défis plus complexes qu'initialement anticipé :

1. La nouvelle bibliothèque est conçue exclusivement pour InfluxDB2, ce qui pourrait compromettre la compatibilité pour les utilisateurs de la version InfluxDB1.

2. Les méthodes d'authentification diffèrent significativement entre les versions : InfluxDB2 utilise un système de token, tandis que la version précédente fonctionne avec un couple login/mot de passe.

Considérant ces éléments, je recommande de procéder en deux phases :

• À court terme : maintenir la dépendance actuelle (influxdb/influxdb-php v1.15) pour assurer la stabilité et la compatibilité avec les installations existantes, comme proposé dans la PR Correction de la dépendance InfluxDB dans composer.json pour compatibilité avec le code actuel #3038.
• À moyen terme : développer une solution capable de supporter les deux versions d'InfluxDB, potentiellement via un plugin dédié qui offrirait une interface commune tout en gérant les spécificités de chaque version.

Cette approche permettrait de réduire les risques de régression tout en préparant une migration progressive vers les versions plus récentes d'InfluxDB

Je viens de modifier l’issue en ce sens.

[kwizer15]

En réfléchissant à la solution n°2 (développer une compatibilité avec les deux versions d'InfluxDB), je viens de découvrir qu'il existe déjà un plugin développé par @Mips2648 qui semble faire exactement ce que nous cherchons à implémenter : il gère à la fois InfluxDB 1.8+ et InfluxDB2 (https://mips2648.github.io/jeedom-plugins-docs/influxdb).

@Mips2648 , pourrais-tu nous confirmer les capacités exactes de ton plugin par rapport à la fonctionnalité actuelle du core ? Est-il complètement compatible avec les deux versions d'InfluxDB ?

Cette découverte soulève une question importante : étant donné que ce plugin est payant (2€), devrions-nous :

1. Continuer à maintenir et développer cette fonctionnalité en double dans le core ?
2. Ou envisager de supprimer progressivement cette fonctionnalité du core et rediriger les utilisateurs vers ton plugin ?

J'aimerais avoir vos avis sur ce sujet. Pour l'instant, comme solution immédiate, je maintiens que nous devrions revenir à "influxdb/influxdb-php": "^1.15" via la PR #3038 pour assurer la stabilité du système.

[Mips2648]

Mon plugin supporte v1.8 (pas les versions < 1.8) et v2 (comme indiqué dans la doc que tu as déjà trouvée).
Je tiens à préciser qu'il existait avant que le core ne gère (en partie) un export vers influxDB

Quand à garder ou pas la fonctionnalité dans le core, on pourrait dire que mon avais ne sera pas objectif mais la question tourne plutôt autour de:

est-ce la responsabilité du core d'intégrer des solutions externes?

par exemple, si influxDB est intégré, pourquoi pas mqtt (et là on a un plugin) ou une autre solution de time-series telle que Prometheus concurrent direct de influxDB?

Et à mon avis c'est non, ce ne devrait pas être la responsabilité du core

[kwizer15]

C’est mon avis aussi, surtout qu’il y a eu une initiative pour retirer la dépendance (et donc sous-entendu la fonctionnalité).
Il faudrait simplement qu’une solution soit actée et implémentée un minimum proprement. Retirer simplement une dépendance composer sans supprimer le code associé occasionne des problèmes.
Merci pour ta réponse.

[Mips2648]

oui, mais je sais bien (comme tout le monde) que ca va provoquer un tollé général si cette fonction est retirée au "profit" d'un (vulgaire ;-) ) plugin tiers ... et en plus il est payant, le scélérat!

[kwizer15]

Je propose juste des possibles solutions, j’estime que ce n’est pas à nous d’acter ce genre de décision.
L’urgence c’est la stabilité du code, je suis même surpris qu’on n’ai pas encore eu de remontée sur ce bug qui semble répétitif.

Honnêtement, le fait que ce genre de plugin soit payant ne me choque pas. Si quelqu’un souhaite en faire un gratuit rien ne l’en empêche.