Dieses Update schlägt bei mir fehl, und im Moment sind alle meine 3 Discourse-Foren ausgefallen.
Das Konsolenfenster auf dem Upgrade-Bildschirm wird nicht mit etwas gefüllt, aber der Rest der Benutzeroberfläche deutet darauf hin, dass das Upgrade noch läuft (aber dies hat bereits viel länger gedauert als jedes Update, das ich je durchgeführt habe).
Erleben andere das auch? Gibt es Ideen, wie ich das Upgrade erfolgreich abschließen kann?
@pearsonified Da dies eine Aktualisierung der Rails-Komponente beinhaltet, ist dies eine dieser Veröffentlichungen, die ein Update von der Kommandozeile erfordern.
Ahh, ist das das Problem mit dem Ruby 3.0-Fehler und web-push-3.0.0?
Die Admin-Upgrade-Web-UI sollte dem Benutzer das mitteilen, anstatt ihn auf „Alle upgraden“ klicken zu lassen und mit einem völlig kaputten Forum zu enden. Das erspart vielen Benutzern Herzklopfen.
Keine Ahnung; ich persönlich benutze nie die GUI für Updates, ich mache sie persönlich immer über die Kommandozeile. Ich habe keine Fehler gesehen, die so aussahen. Aber dann hätte ich sie auch nicht gesehen.
Meistens, wenn man eine generische Fehlermeldung sieht, wenn das spezifische Szenario ausreichend vorhergesehen wurde, um eine spezifische Fehlermeldung zu erzeugen, wäre es stattdessen vermieden worden.
Ich schätze, es ist gut, dass das Problem “Hilfe, mein GUI-Update ist fehlgeschlagen” so selten ist, dass die meisten Leute nicht erkennen, dass das Erste, was man tun sollte, ist, git pull; ./launcher rebuild app für die Standardbereitstellung auszuführen. Es ist fast immer die Antwort hier.
Aber es ist die allgemeine Vorgehensweise, wenn das GUI-Update fehlschlägt.
Ich benutze Discourse jetzt schon seit vielen Jahren. So ungefähr 7? Wie auch immer, noch nie ist ein Web-Upgrade katastrophal fehlgeschlagen. Es ist natürlich fehlgeschlagen, aber das Forum ist immer wieder zum Leben erwacht, weil es zurückgerollt und den alten Container gestartet hat.
Es ist kein generischer Fehler, das Ruby-Problem ist ziemlich klar.
web-push-3.0.0 erfordert Ruby-Version >= 3.0, was mit der
aktuellen Version 2.7.6 inkompatibel ist
Docker Manager: UPGRADE FEHLGESCHLAGEN
Ich würde mich ziemlich lautstark beschweren, wenn ich für Discourse bezahlen würde. Nicht weil es einen riesigen Bug gab, der unser Forum lahmgelegt hat, Bugs passieren, sondern weil er in den letzten 3 Tagen nicht behoben wurde. So wie es ist, nur ein bisschen Aufregung am Ende des Tages.
Aus Sicht des Docker-Managers wusste dieser Code zum Zeitpunkt, als die bereits laufende Version geschrieben wurde, nicht, dass dieses Problem in Zukunft auftreten würde. Ich verstehe, dass Sie frustriert sind, aber Ihre Anfrage ist möglicherweise technisch nicht sinnvoll.
Wenn Sie für Discourse bezahlt hätten, würden diese den Prozess verwalten und Sie würden ihn nie sehen. 
Selbst wenn es technisch unmöglich ist, es zu beheben, könnten Sie den Benutzern E-Mails senden, um sie zu warnen, dass sie über die CLI ein Upgrade durchführen müssen. Machen Sie Lärm darum. Foren zu zerbrechen, ohne ein Rollback zu ermöglichen, ist schlecht.
Ich dachte, Discourse verkauft auch Support für die On-Premise-Nutzung? Wie auch immer, ich kann mich nicht zu laut beschweren, da ich kein zahlender Kunde bin, aber meine Güte, 3 Tage sind nicht gerade toll.
Ich freue mich für Sie, dass Sie zum ersten Mal seit sieben Jahren auf diese Weise zurückgreifen mussten, aber:
Ich werde das als Falschdarstellung bezeichnen. CDCK empfiehlt tatsächlich Backups vor Updates als bewährte Methode. Ich habe hier auf Meta schon oft den Hinweis gesehen, dass bei einem Fehlschlag des GUI-Updates ein Zurückgreifen auf den Wiederaufbau über die Kommandozeile als Teil der normalen Erwartungen für die Verwaltung Ihres eigenen Forums erfolgt. Sie haben die Foren nicht ohne Rollback kaputt gemacht, daher ist Ihre Unterstellung falsch.
Ich werde hier nicht stundenlang streiten. Ich denke nur, Sie sind hier nicht ganz vernünftig.
Darüber hinaus ist das Upgrade eines Produktionsservers, ohne dieses Upgrade durch eine Art Staging-Umgebung laufen zu lassen, geradezu eine Einladung zum Schmerz.
Es muss keine vollständige Kopie sein, ein $5 VPS reicht für die meisten aus. Wenn Sie Ausfallzeiten und die Notwendigkeit, auf Ihre Backups zurückzugreifen, vermeiden wollen, ist dies die günstigste Versicherung, die Sie bekommen können.
Ich habe dies gerade auf einer Test-DO-Instanz ausprobiert, die seit Ewigkeiten nicht mehr aktualisiert wurde:
und wie berichtet, ist ein Fehler aufgetreten:
Fetching gem metadata from https://rubygems.org/.........
Fetching https://github.com/rails/sprockets
web-push-3.0.0 requires ruby version >= 3.0, which is incompatible with the
current version, 2.7.6
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:209:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:93:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:20:in `block in fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands.rb:18:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Spinning up 3 Unicorn worker(s) that were stopped initially
und die Upgrade-Seite zeigt jetzt:
und die Hauptseite gibt einen 500er-Fehler aus. In /logs sehe ich diesen Fehler:
NoMethodError (undefined method `navigation_menu' for #<Class:0x00007fdffcb1b2f8>)
lib/wizard/builder.rb:98:in `block in build'
lib/wizard.rb:25:in `append_step'
lib/wizard/builder.rb:61:in `build'
lib/wizard.rb:110:in `requires_completion?'
lib/wizard.rb:117:in `user_requires_completion?'
app/serializers/site_serializer.rb:171:in `include_wizard_required?'
...
@pearsonified @mcdanlj Können Sie bitte die Fehler einfügen, die Sie erhalten haben?
Ich weiß nicht, ob wir jetzt etwas tun können, um dies für zukünftige Benutzer zu verhindern, aber wir werden uns darum kümmern.
In der Zwischenzeit, haben die folgenden Schritte geholfen?
Ich werde heute Morgen die Befehlszeilen-Upgrades ausführen und sehen, wie das läuft. Die Foren sind jetzt seit 18 Stunden offline 
Wenn Sie mich fragen würden, ja, der CLI-Neustart hat gut funktioniert. Ich bin ein anständiger SA und habe die Lösung hier im Forum gefunden, aber es sieht so aus, als ob andere Forenbesitzer wie @pearsonified stark beeinträchtigt waren. 18 Stunden Ausfallzeit, oof.
Leute, die über Staging- und Produktionsumgebungen sprechen, sind verrückt. Es gibt viele nicht-korporative Leute, die Discourse-Foren auf kleinen VMs hosten. „Sie sollten in einer Staging-Umgebung testen“ ist eine beleidigende, scheinheilige Antwort, die ihre Installation in keiner Weise rechtfertigt. Nichts rechtfertigt das.
Ich möchte nur betonen, dass ich es schätze, dass diese exzellente Software völlig kostenlos ist. Dafür bin ich dankbar, und die gelegentlichen Stolpersteine ändern nichts an meinen Gefühlen.
Discourse ist kostenlos, Server, Domains und unsere Zeit nicht.
Das hat nichts mit Unternehmensumgebungen zu tun, es ist einfach gesunder Menschenverstand, wenn so viele Variablen im Spiel sind. Es wird viel Arbeit geleistet, um Upgrades nahtlos zu gestalten, und wenn Sie lieber Ihre Zeit kostenlos aufwenden möchten, um erhebliche Störungen zu beheben, ist das Ihre Entscheidung – aber persönlich ziehe ich es vor zu wissen, dass die gemeinnützigen und freiwilligen Gemeinschaften, die ich hoste, für ein schmerzfreies Upgrade einmal ausfallen, im Gegensatz zu einem langwierigen Zeitraum.
Der kleinste VPS bei DO reicht aus, um Upgrades zu de-risiken, solange der Test repräsentativ ist – wenn Sie ein anständiger SA sind, sind diese 5 US-Dollar die Kosten für eine Tasse Kaffee und ein Bruchteil Ihres stündlichen Marktpreises.
Die Staging-VM müsste auch die Daten des Forums speichern, was unsere Hosting-Kosten verdoppeln würde. Sie ist sowieso nicht notwendig, es ist ein Videospiel-Forum und ein bisschen Ausfallzeit (nicht 18 Stunden!) ist in Ordnung. Im schlimmsten Fall hatte ich einen VM-Snapshot vor dem Upgrade, sodass ich ihn einfach zurückrollen hätte können.
Ich finde die 4 Tage, die es kaputt geblieben ist, besorgniserregend. Fehlgeschlagene Upgrades ohne Rollback sollten einen echten “Heilige Scheiße, das muss JETZT behoben werden”-Moment auslösen. Das sollte keine kontroverse Aussage sein.
Ich habe auch den Web-Push-Ruby-Fehler erhalten. Normales Forum, keine benutzerdefinierten Plugins.
web-push-3.0.0 erfordert Ruby-Version >= 3.0, was mit der aktuellen Version 2.7.6 inkompatibel ist
Es gab in der Vergangenheit Zeiten, in denen gesagt wurde, dass es über die Befehlszeile aktualisiert werden muss. Vielleicht könnte diese Option jetzt für jede Version aktiviert werden, die dieses Problem verursacht?
Bearbeiten: Oh, das steht tatsächlich da!
Das Problem ist, dass, wenn Sie ein docker_manager Update durchführen und dann einfach auf den Tab oben klicken, anstatt die Seite zu aktualisieren. Könnte es also so geändert werden, dass es über HTTP aktualisiert wird, anstatt nur Tabs mit JS zu wechseln?