Wie mit neuen Abhängigkeiten in bestehendem Modul umgehen?

[Benni]

Damit es nicht untergeht....


... hier gibt es noch eine Paralleldiskussion: https://forum.fhem.de/index.php/topic,71471.msg629763.html#msg629763

[Thorsten Pferdekaemper]

Ok, ich habe da auch mal meinen Senf dazugegeben.
Gruß,
   Thorsten

[Reinerlein]

Hallo,

könnte man nicht, analog zur integrierten Dokumentation, einen Bereich im Quelltext markieren, indem sich eine "Pre-Check-Funktion" befindet, die bei vorhandensein einfach per eval ausgeführt wird, und deren Ergebnis über die weitere Vorgehensweise von Update entscheidet?
Wenn da ein "false" (o.ä. wie "0") zurückkommt, wird das Update abgebrochen und zurückgerollt. Eine entsprechende Logausgabe sollte diese Funktion vor der Rückgabe an den Aufrufer (also update) selber wegschreiben...

Diese Funktion könnte auch vom Modul-Initialisierungsprozess verwendet werden, und vor dem Einrichten eines Devices damit Abhängigkeiten prüfen lassen. Das bleibt ja identisch.

Damit könnten alle Module, die das so implementieren, ohne Fehler gestartet werden, da fehlende Module (und andere Vorbedingungen) bereits in dieser Pre-Check-Funktion überprüft worden sind (sofern sauber vom Entwickler gemacht )

Code z.B.

Code Auswählen Erweitern


=pod
.
.
=begin precheckfunction
..Code zum Prüfen der Bedingungen und entsprechender Logausgabe und Rückgabe von 0 im Fehlerfall..
return 1;
=end precheckfunction
.
.
=cut


Oder gibt es Dinge, die man nicht in einen solchen Bereich schreiben darf? Da kenne ich mich zu wenig mit aus...

Grüße
Reinerlein

[rudolfkoenig]

 Diese Loesung gefaellt mir nicht: Damit wuerde ich (der aktuell HM485 nicht nutzt), bei jedem update unsanft daran erinnert, dass ich kein XML::Simple installiert habe. Und wenn die alte HM485-Doku den Rest vom commandref kaputtmacht, dann wird das in meiner Installation erst dann gefixt, wenn ich XML::Simple installiert habe.

[igami]

Also brauchen wir ein CPAN Modul welches beim define die benötigten Module nachinstalliert und neue Routinen für Entwickler mitbringt um in bestehenden Modulen darauf zu prüfen 

Es gibt sogar ein Perl Modul für CPAN
https://metacpan.org/pod/distribution/CPAN/scripts/cpan

[Reinerlein]

Hi Rudi,

wieso?
Natürlich muss eine Prüfung rein, dass das beim Update nur bei bereits geladenen Modulen geprüft wird.
Ich dachte so etwas gäbe es sowieso schon, oder kommt die Meldung mit dem notwendigen Neustart am Ende immer? Ich dachte die käme nur, wenn ein Modul geupdatet wurde, welches aktuell geladen und damit verwendet wird...

Grüße
Reiner

[Reinerlein]

Hi igami,

das wäre eher blöd, da man ja nicht immer unter allen Umständen ein Modul verwenden möchte. Ich mache das oft daran fest, was ich noch alles nachinstallieren müsste, und ob ich das dann überhaupt noch will...
u.U. gibt es ja auch Konflikte mit bestehenden Perl-Modulen usw.

Dieser Pre-Check gäbe mir genau diese Möglichkeit an die Hand...

Grüße
Reiner

[zap]

Wenn man so einen Precheck einführt, müsste auf jeden Fall auch die Version des CPAN Moduls mit rein. Auch mit verschiedenen Versionen gibt es immer wieder Überraschungen.

Allerdings ist der Precheck zumindest für mich kein Must-Have. Ich lebe schon seit (vielen) Jahren mit solchen Abhängigkeiten. In Perl sind es die Module, in C irgendwelche Shared Libraries, in Windows DLLs.

Nicht umsonst gibt es v.a. unter UNIX die "dependency hell". 😉

[Reinerlein]

Hi zap,

das stimmt wohl, und müsste von den Authoren der Module sinnvoll geprüft werden (was vermutlich nicht in allen Fällen sauber geht, aber dann startet das Device wenigstens erstmal, und macht vielleicht nicht mehr ganz das was es soll).
Hier geht es aber in erster Linie um eine nachträgliche, zusätzliche Abhängigkeit, die plötzlich nach einem Update zu einem Nicht-Funktionieren der Haussteuerung führen würde, bzw. die Konfiguration nachhaltig verändert...

Meiner Meinung nach darf bei einer Haussteuerung, die stets stabil lauffähig sein muss, niemals ein Update durchgeführt werden, dass zu einer (Teil-)Nichtfunktion der Steuerung führt, wenn es verhinderbar gewesen wäre. Solche neuen Abhängigkeiten können immer wieder vorkommen, es soll ja schließlich auch weitergehen mit den Modulen, und sollte dementsprechend abgefangen werden...

Ich beschäftige mich gerne mit meiner Steuerung, brauche aber auch eine gewisse Stabilität, da ich manchmal auch "aus Versehen" ein Update mache, und dann nicht stundenlang auf Fehlersuche gehen möchte.
Mich hat z.B. auch die "Zwangsaktivierung" des CSRFTokens massiv gestört. Das ging für mich schon in den Bereich der Bevormundung, da nach dem Update erstmal einiges nicht funktionierte. So etwas sollte man, und kann man auch recht einfach, anders einführen...

Was spricht denn nun wirklich gegen eine Vorabprüfung auf Modulfreiwilliger Basis von verwendeten/aktiven Modulen während des Update-Prozesses, mit der Möglichkeit dadurch das Update zurückzurollen/zu verhindern?
Ist es der Aufwand? Der hält sich bei meinem Vorschlag doch noch in Grenzen. Da sind ja wieder in Teilen die Modulauthoren gefragt, die den Part pflegen müssen...
Soweit ich weiß, kann das Update doch bereits ein "Rollback" durchführen, wenn eine Datei nicht geladen werden konnte. Also wäre die Hauptaufgabe nach dem Herunterladen eines Moduls dessen Precheck zu extrahieren (z.B.

Code Auswählen Erweitern

/=pod.*?=begin precheckfunction[\r\n]+(.*?)=end precheckfunction.*?=cut/is sicherlich noch ausbaufähig ) und per eval auszuwerten, und je nach Ergebnis weiterzumachen oder ein "Rollback" durchzuführen...
Oder übersehe ich da etwas?

Grüße
Reinerlein

[Thorsten Pferdekaemper]

Hi,
da habe ich anscheinend eine ganz schöne Diskussion losgetreten.

Diese Loesung gefaellt mir nicht: Damit wuerde ich (der aktuell HM485 nicht nutzt), bei jedem update unsanft daran erinnert, dass ich kein XML::Simple installiert habe. Und wenn die alte HM485-Doku den Rest vom commandref kaputtmacht, dann wird das in meiner Installation erst dann gefixt, wenn ich XML::Simple installiert habe.

Mit HM485 würde Dir das zwar wahrscheinlich nicht passieren, da man das mit "update add" erst einmal hinzufügen muss. ...und wenn man das getan hat, dann verwendet man es wahrscheinlich auch.
Prinzipiell gebe ich Dir aber Recht.
Das ganze in die Doku zu packen halte ich auch für keine so gute Idee. Wenn man so etwas machen will, dann wäre es meiner Meinung nach besser, dafür ein neues Verzeichnis anzulegen (z.B. updateCheck), in dem Dateien liegen, die denselben Namen wie die zugehörige Moduldatei hat. (Also bei mir z.B. updateCheck/00_HM485_LAN.pm.) Diese Datei hat dann eine sub (oder wird halt einfach komplett ausgeführt), die entweder undef oder eine Fehlermeldung zurückliefert.
Der update-Prozess müsste meiner Meinung nach dann in etwa so gehen:
1. Zuerst alle updateCheck-Dateien herunterladen.
2. Alle updateCheck-Dateien ausführen, zu denen es ein gleichnamiges geladenes Modul gibt.
3. Falls vorhanden: updateCheck-Meldungen ausgeben und update abbrechen (und updateCheck-Dateien wieder auf den alten Stand bringen)
4. Ansonsten normal weiter

Ich glaube, dass dieses Vorgehen funktionieren würde und alle angesprochenen Probleme vermeidet. Allerdings glaube ich nicht, dass ich selbst das tatsächlich verwenden werde, da bis das vorhanden ist, der Zug schon abgefahren sein dürfte.

Wenn man so einen Precheck einführt, müsste auf jeden Fall auch die Version des CPAN Moduls mit rein. Auch mit verschiedenen Versionen gibt es immer wieder Überraschungen.

Das müsste man dann der jeweiligen Implementierung im Modul überlassen.

Ich beschäftige mich gerne mit meiner Steuerung, brauche aber auch eine gewisse Stabilität, da ich manchmal auch "aus Versehen" ein Update mache, und dann nicht stundenlang auf Fehlersuche gehen möchte.
Mich hat z.B. auch die "Zwangsaktivierung" des CSRFTokens massiv gestört. Das ging für mich schon in den Bereich der Bevormundung, da nach dem Update erstmal einiges nicht funktionierte. So etwas sollte man, und kann man auch recht einfach, anders einführen...

Das ist jetzt zwar ein anderes Thema, aber meiner Meinung nach war Rudis Vorgehen hier vorbildlich. Es hat ja eine ganze Weile gedauert, bis das scharf geschaltet wurde. Die meisten Probleme gab es ja, weil Modulautoren es verpennt hatten, darauf zu reagieren (mea culpa...).

Gruß,
    Thorsten

[rudolfkoenig]

Meiner Meinung nach darf bei einer Haussteuerung, die stets stabil lauffähig sein muss, niemals ein Update durchgeführt werden, dass zu einer (Teil-)Nichtfunktion der Steuerung führt, wenn es verhinderbar gewesen wäre.

Meine Meinung: Wenn man auf einem Produktivsystem ein update macht, dann testet man es vorher auf einem Testsystem. Genauso, wie auf "richtigen" Produktionssystemen, da kostet ein Upgrade auch Energie/Zeit und damit Geld. Keiner ist gezwungen, ein update zu machen. Wenn man FHEM (wie die meisten) als Spielwiese betrachtet, dann ist ein Ausfall nach einem update kein wirkliches Problem, man kann ja immer zurueckrollen, notfalls aus einem backup.

Mich hat z.B. auch die "Zwangsaktivierung" des CSRFTokens massiv gestört.

Weiss nicht, was genau dich daran stoert:
- dass du als Benutzer betroffen bist: ich will es nicht in den Medien lesen, dass ich (als "Hersteller") Schuld bin, wenn ein "Hacker" mit FHEM Schaden anrichtet, weil ich elementare Sicherheitsmaengel, die vor Jahren gemeldet wurden, nicht behoben habe.
- dass du als Entwickler betroffen bist: Hoffentlich erhoeht das die Aufmerksamkeit auf meine Bitten, ein Feature zu testen. Dieses Feature war 1.5 Jahre vorhanden, ich habe mit 5.8 nur die Voreinstellung geaendert.

Was spricht denn nun wirklich gegen eine Vorabprüfung auf Modulfreiwilliger Basis von verwendeten/aktiven Modulen während des Update-Prozesses, mit der Möglichkeit dadurch das Update zurückzurollen/zu verhindern?

Dass es nur in sehr wenigen Faellen (wie hier) hilft, und sehr wahrscheinlich mir unbekannte Nebeneffekte hat, mit dem ich mich "Jahrelang" rumplagen werde.

/=pod.*?=begin precheckfunction[\r\n]+(.*?)=end precheckfunction.*?=cut/is

Ich kann das einbauen, falls Andere das auch als notwendig erachten. Ich wuerde das fuer alle aktuell geladene "Haupt"-Module (keine Hilfsmodule) durchfuehren. Falls es schiefgeht, dann wuerde ich versuchen alles zurueckzurollen. Ist vermutlich 3-4 Stunden Aufwand, es zu impementieren.

@Thorsten: dein Vorschlag ist mir weniger sympatisch, da man dadurch Aufgaben verteilt, und man diese selten benutzte Ecke eher vergisst. Ich lasse mich aber ueberzeugen.

[Thorsten Pferdekaemper]

Dass es nur in sehr wenigen Faellen (wie hier) hilft, und sehr wahrscheinlich mir unbekannte Nebeneffekte hat, mit dem ich mich "Jahrelang" rumplagen werde.

Wahrscheinlich insbesondere da der Befehl "update" dann zu Problemen führt und es relativ wahrscheinlich wird, dass die Probleme in irgendwelchen allgemeinen Bereichen im Forum aufschlagen und nicht unbedingt im Bereich zum betroffenen Modul.

Ich kann das einbauen, falls Andere das auch als notwendig erachten. Ich wuerde das fuer alle aktuell geladene "Haupt"-Module (keine Hilfsmodule) durchfuehren. Falls es schiefgeht, dann wuerde ich versuchen alles zurueckzurollen. Ist vermutlich 3-4 Stunden Aufwand, es zu impementieren.
@Thorsten: dein Vorschlag ist mir weniger sympatisch, da man dadurch Aufgaben verteilt, und man diese selten benutzte Ecke eher vergisst. Ich lasse mich aber ueberzeugen.

Ich persönlich fände das ziemlich "unordentlich", so etwas in der Doku zu verstecken. (Ich finde auch schon die Doku im .pm-File unordentlich.) Ich gebe aber zu, dass diese Ecke wahrscheinlich eher selten benutzt werden wird und dadurch in Vergessenheit geraten kann. Ich bin mir aber nicht sicher, ob es wirklich hilft, alles in eine Datei zu legen.
Ich wünsche mir sowieso schon seit längerem, dass jedes Modul sein eigenes Verzeichnis bekommt. Dann hätte man z.B. /opt/fhem/FHEM/10_HM485 als Verzeichnis und könnte dort alles reinpacken, was ein Modul so braucht (wie z.B. auch meine XML-Dateien). Man könnte dann auch schön Doku von Code trennen und auch solches Check-Coding separat halten. Eine ähnliche Diskussion gab es auch rund um einen Mechanismus zum automatischen Erkennen von (Netzwerk-)Geräten, bei denen man auch nicht zuerst die Moduldatei laden will, nur um dann zu erkennen, dass es dazu gar kein Gerät gibt.
 
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
ich habe das jetzt für HM485 so "gelöst":
Der problematische Teil wird per "eval" geladen und $@ wird ausgewertet. Falls nötig, werden die Devices in FHEM "blockiert" und der Fehler erscheint im Log. Außerdem wird per FW_detailFn eine detaillierte Fehlermeldung ausgegeben. Das sollte reichen.
Gruß,
   Thorsten