Vielen Dank für die Übermittlung. Das macht Sinn. Es ist auch mit # 1111 als Teil des Gesamtbildes verwandt.

Wir würden auf jeden Fall PRs dafür akzeptieren, aber wir müssten eng zusammenarbeiten und dies intern weiter diskutieren. Wären Sie auch bereit, ein mittelgroßes Dokument darüber zu schreiben, wie Sie mit der Fehlerbehebung, fortlaufenden Updates und dem Starten von Aufgaben umgehen?

Ich habe einige weitere Informationen darüber zusammengestellt, wie wir dachten, dass dies funktionieren würde. Es dauerte nicht so lange, also wenn es irgendetwas gibt, worüber Sie mehr Details wollen, lassen Sie es mich wissen und ich werde es erweitern.

Gesamt

Wenn eine Aufgabe als fehlerfrei markiert wird, wird das Entfernen einer alten Aufgabe für updateDelay Sekunden in der Zukunft geplant.

Fehlerbehebung

Diese Änderung hat keine Auswirkungen auf die Fehlerwiederherstellung. Das updateDelay verzögert nur das Entfernen alter Instanzen.

Laufende Updates

Die updateDelay würde fortlaufende Updates verlangsamen. Nachdem jeder Batch des Updates erfolgreich war, wird das Entfernen alter Aufgaben verzögert. Insgesamt wird das Update um updateDelay * die Anzahl der Update-Batches verzögert. Ein Batch gibt an, wie viele Aufgaben gleichzeitig während eines fortlaufenden Updates aktualisiert werden.

Aufgaben starten

Diese Änderung hat keine Auswirkungen auf das Starten von Tasks. Es gibt keine alten Aufgaben, deren Entfernung verzögert werden könnte.

Hey @pgkelley4 , danke, dass du den Code weiterverfolgt hast, und entschuldige, dass du etwas langsam reagierst.

Ich denke, dass das Problem etwas komplizierter sein könnte, als Ihr Commit vermuten lässt. Wenn Marathon während eines Upgrades ausfällt, funktioniert Ihr Code nicht. Es wird auch eine Aufgabe fälschlicherweise beenden, wenn die gesund gewordenen Aufgaben ungesund werden, während das Töten verzögert wird.

Ich denke, es würde helfen, wenn Sie die Verzögerung nicht als "killOldTasksDelaySeconds" betrachten, sondern als (nur ein Beispiel) "minHealthyDuration". ZB im Rahmen des rollierenden Upgrades betrachten wir nur Aufgaben als gesund, die mindestens diese Zeit gelebt haben.

Können Sie vielleicht Dokumentation für Ihre Lösung bereitstellen? Manchmal hilft es zu beurteilen, ob die Lösung angenehm zu bedienen oder etwas ungeschickt ist.

@Kolloch , vielen Dank, dass Sie sich die Zeit genommen haben, sich meine PR anzusehen und mit mir daran zu arbeiten.

Wenn Marathon während eines Upgrades ausfällt, funktioniert Ihr Code nicht.

Ganz vergessen, das zu berücksichtigen. Nachdem ich mir die Klasse jedoch genauer angesehen habe, denke ich, dass es noch einige weitere Probleme gibt, die auftreten können, wenn Marathon während eines Updates ausfällt.

Ich habe einen Schnelltest zusammengestellt, um dies zu überprüfen. Ich habe ein Update für eine 2-Instanzen-App gestartet und dann den Master neu gestartet. Der neue Master hat den Bereitstellungsplan problemlos übernommen, aber er würde zu viele Aufgaben töten und unter die minimale Gesundheitskapazität fallen (nicht jedes Mal).

Ich glaube, das liegt daran, dass die Methode TaskReplaceActor.preStart davon ausgeht, dass sie einmal zu Beginn eines Updates ausgeführt wird und dann:

• taskToKill berücksichtigt nicht, dass einige möglicherweise die neue Version sind und möglicherweise nicht fehlerfrei sind (häufig der Fall bei einem Update). Aus diesem Grund ist nrToKillImmediately falsch und beendet Aufgaben sofort.
• conciliateNewTasks weiß nicht, dass Aufgaben zuvor gestartet wurden.
• Die Backoff-Verzögerung wird jedes Mal zurückgesetzt.

Dies kann behoben werden, indem die preStart-Methode so geändert wird, dass davon ausgegangen wird, dass die Dinge bereits gestartet wurden. Gerne erstelle ich für diese Themen eine separate PR. Aber lassen Sie mich wissen, wenn mir hier im Code etwas völlig fehlt, und ich werde die funktionalen Probleme melden, die ich als Fehler gesehen habe.

Speziell in Bezug auf meine Ergänzung werden derzeit Zustandsprüfungsinformationen wie firstSuccess während eines Failovers nicht beibehalten. Daher halte ich es für sinnvoll, die Kill-Verzögerung nach einem Failover neu zu starten. Ich kann diese Änderung vornehmen, wenn Sie damit einverstanden sind.

Es wird auch eine Aufgabe fälschlicherweise beenden, wenn die gesund gewordenen Aufgaben ungesund werden, während das Töten verzögert wird.

Ich hatte dazu einen Kommentar zur PR hinzugefügt. Ich war mir nicht 100% sicher, ob dies das beste Verhalten war. Nach längerer Überlegung stimme ich deiner Beschreibung zu. Ich kann das auch reparieren.

Ich denke, es würde helfen, wenn Sie die Verzögerung nicht als "killOldTasksDelaySeconds" betrachten, sondern als (nur ein Beispiel) "minHealthyDuration". ZB im Rahmen des rollierenden Upgrades betrachten wir nur Aufgaben als gesund, die mindestens diese Zeit gelebt haben.

Ich kann es sicherlich so ändern, wenn Sie es für besser halten. Uns ist also klar, dass wir über dasselbe sprechen: Ich denke, Sie meinen, dies vom Paket mesosphere.marathon.health aus anzugehen und so etwas zu tun, wie HeathStatusChanged nicht als gesunde Ereignisse zu veröffentlichen, bis ein bestimmter Zeitraum verstrichen ist (nicht sicher, ob das genau so ist wie es umgesetzt werden soll).

Was mir am killOldTasksDelaySeconds-Ansatz gefallen hat, ist, dass er nur Updates betrifft und der Benutzer so viele Informationen wie möglich erhält. Ich dachte, dass es unerwünscht wäre, App-Starts und die Fehlerwiederherstellung zu verlangsamen. Es kann jedoch konsistenter sein, die Verzögerung auf alle neuen Aufgabenerstellungen anzuwenden.

Hier ist die Dokumentation, die ich vorher hatte:

killOldTasksDelaySeconds (Optional. Default: 0) - The amount of time in seconds to wait to kill an old task when a new task becomes healthy.

Hier ist, was ich denke, der neue Weg wäre:

minHealthyDuration - The amount of time a task must be passing its healthchecks before marathon considers it to be healthy.

Möchten Sie trotzdem, dass ich zu minHealthyDuration ändere? Ich freue mich, wenn ja, eine PR für diesen Ansatz aufzustellen.

Entschuldigung, dass ich so viel auf einmal auf Sie geworfen habe, und nochmals vielen Dank!

@kolloch Könntest du dir das bald mal anschauen? Ich möchte nicht, dass es durchfällt ... Ich bin froh, den Fehler auf ein separates Ticket aufzuteilen.

Hey @pgkelley4 , nur eine kurze Anmerkung: Es tut mir leid, dass ich diese Kommentare verpasst habe! Ich war sehr beschäftigt und habe ein paar Benachrichtigungen von Github zu viele archiviert. Ich werde mir jetzt zumindest deine Kommentare durchlesen.

Hallo @pgkelley4 , danke für den tollen Kommentar!

Sie haben Recht mit den Fehlern, denke ich (ich würde etwas mehr Zeit brauchen, um das sicher zu überprüfen). Es wäre toll, dafür ein separates Ticket zu erstellen.

Ich kann es sicherlich so ändern, wenn Sie es für besser halten. Uns ist also klar, dass wir über dasselbe sprechen: Ich denke, Sie meinen, dies vom Paket mesosphere.marathon.health aus anzugehen und so etwas zu tun, wie HeathStatusChanged nicht als gesunde Ereignisse zu veröffentlichen, bis ein bestimmter Zeitraum verstrichen ist (nicht sicher, ob das genau so ist wie es umgesetzt werden soll).

Ich denke, Sie haben Recht damit, dass die Gesundheitsinformationen so schnell wie möglich an die Verbraucher der API weitergegeben werden sollten. Ich dachte nur daran, es als verzögerten Gesundheitszustand innerhalb der Bereitstellungslogik zu behandeln. Es würde besser funktionieren, wenn der Gesundheitszustand schuppig ist oder die Aufgaben sterben. Der Ansatz, den Sie in der PR verfolgen, ist ein bisschen gefährlich. Wenn Sie einen Konfigurationsfehler haben, der dazu führt, dass alle Aufgaben nach 10 Sekunden sterben, und Sie eine killOldTasksDelaySeconds von 20 Sekunden haben, beenden Sie immer noch die alten (funktionierenden) Aufgaben, obwohl Sie keine neuen Aufgaben haben, um sie zu ersetzen.

Ich bin wirklich begeistert von dieser Arbeit, aber ich wollte nur einen Vorschlag hinzufügen. Es wäre großartig, wenn es eine Möglichkeit gäbe, festzustellen, dass eine Aufgabe von der API "nicht mehr funktioniert". Auf diese Weise könnte es von Load Balancern und DNS entfernt werden, bevor es tatsächlich gelöscht wird. Dies würde es einfach machen, nahtlose Übergänge zwischen Versionen bereitzustellen.

Hallo,

Ich wollte gerade eine Feature-Anfrage für genau das Feature stellen, das @kevincox gemacht hat, ich bin froh, dass ich das zuerst gefunden habe :)

Was ich naiv gehofft hatte, war ein Ereignis von TaskScheduledForRemoval oder so etwas. Mir ist klar, dass dies etwas schwierig sein wird, wenn dies als Verzögerung für den fehlerfreien Zustand der neuen Instanz und nicht als Planungsereignis für die alte Instanz implementiert wird.

Danke,

Ich würde auch gerne etwas im Veranstaltungsbus sehen, da @sgran und @kevincox vorgeschlagen haben, bei der Planung der Entfernung aus LBs/etc.

Wir versuchen, App-Updates ohne Ausfallzeit zu implementieren, und ich denke, das wäre eine große Hilfe.

Derzeit verwenden wir marathon-consul/haproxy-consul, um die haproxy-Konfiguration zu aktualisieren. Wir haben alles gut zum Laufen gebracht, aber ich sehe einen Aussetzer, wenn die alten Instanzen beendet werden. Es scheint, als ob die Zeit zwischen dem Abbruch der Tasks und der Übergabe an den Bus, der Verarbeitung und der Aktualisierung der Konfiguration immer noch einige Probleme verursacht.

Wenn wir ein Ereignis wie vorgeschlagen ( TaskScheduledForRemoval ) oder ähnliches erhalten könnten, könnten wir die Instanzen elegant aus der Konfiguration rotieren, bevor sie getötet werden.

Hinweis: Dieses Problem wurde zu https://jira.mesosphere.com/browse/MARATHON-4535 migriert. Weitere Informationen finden Sie unter https://groups.google.com/forum/#!topic/marathon-framework/khtvf-ifnp8 .