WaCoDiS / job-manager-ui

0 stars 1 forks source link

Jobs Übersicht Liste nach Ausführen/Abbruch eines Jobs updaten #4

Closed VKirstein closed 4 years ago

VKirstein commented 4 years ago

Ein Job der ausgeführt wurde aber abgebrochen ist steht unter der Jobs Übersicht immer noch als Job mit Status waiting. Wenn der Job gescheitert ist sollte er aus der Liste auszuführender Jobs entfernt werden. Auch ausgeführte Jobs aus Jobs Übersicht nach einmaliger erfolgter Ausführung entfernen.

SebaDro commented 4 years ago

Ein Job der ausgeführt wurde aber abgebrochen ist steht unter der Jobs Übersicht immer noch als Job mit Status waiting. Wenn der Job gescheitert ist sollte er aus der Liste auszuführender Jobs entfernt werden.

Bezieht sich diese Anforderung auf Jobs, die nur einmalig ausgeführt werden? Bei Jobs, die intervallmäßig ausgeführt werden, wäre diese Verhaltensweise nämlich korrekt, da der Job, auch wenn er fehlgeschlagen ist, auf den nächsten Ausführungszeitpunkt wartet.

VKirstein commented 4 years ago

Ein Job der ausgeführt wurde aber abgebrochen ist steht unter der Jobs Übersicht immer noch als Job mit Status waiting. Wenn der Job gescheitert ist sollte er aus der Liste auszuführender Jobs entfernt werden.

Bezieht sich diese Anforderung auf Jobs, die nur einmalig ausgeführt werden? Bei Jobs, die intervallmäßig ausgeführt werden, wäre diese Verhaltensweise nämlich korrekt, da der Job, auch wenn er fehlgeschlagen ist, auf den nächsten Ausführungszeitpunkt wartet.

Ja genau ein Job der nur einmal ausgeführt wird. Danke für den Hinweis.

imkeines commented 4 years ago

Dies wird in der UI angepasst wenn der Status in der API zur Verfügung steht.

imkeines commented 4 years ago

Mal eine Überlegung: Wie wäre es, dem/der User/in zu ermöglichen die Jobs in der Anzeige nach Status zu filtern? Als Außenstehende betrachtet würde es für mich schon Sinn ergeben, wenn man sehen könnte ob das Erstellen eines Jobs fehlgeschlagen ist, erfolgreich abgeschlossen, oder noch aktiv ist. Wenn ich mir vorstelle, ich lege einen Job an, und dieser wird nicht angezeigt (eben weil er fehlgeschlagen ist), dann wundere ich mich ja schon, wo mein Job geblieben ist und selbst wenn ich wüsste, dass ein fehlgeschlagener Job nicht angezeigt wird,ventuell würde ich mir den Job nocheinmal ansehen wollen. Wäre es vielleicht also doch sinnvoll, den Status anzuzeigen, egal ob success, running, waiting oder failed, und der User/ die Userin kann dann selbst kontrollieren ob der Job gelöscht werden soll? Zusätzlich mit einem Filter, der ermöglicht, die Jobs nach Status zu filtern?

imkeines commented 4 years ago

Natürlich nur, wenn ihr da so brauchen könnt! Wenn es für euren Workflow einfacher oder angenehmer ist, wenn Jobs, die fehlgeschlagen sind, und/oder bereits fertiggestellt sind, bereits nicht mehr anzuzeigen, dann mach ich das natürlich! Es ist nur eine Idee, die mir als Außenstehende auf-/einfiel.

VKirstein commented 4 years ago

Die Überlegung mit dem Filter finde ich nicht schlecht. Das mit dem Löschen der Jobs die fehlgeschlagen sind oder bereits ausgeführt wurden hatte eigentlich auch nur den Sinn die Anzeige etwas übersichtlicher zu machen. Vielleicht könnte man neben der Filtermöglichkeit dann auch nur für fehlgeschlagene Jobs einen Zeitraum definieren ab wann sie in der Ansicht nicht mehr auftauchen sollen beispielsweise 1 Monat nach Ausführung oder so ähnlich

imkeines commented 4 years ago

Ja, eventuell könnte dies auch systemintern geschehen, sodass bereits erfolgreich ausgeführte Jobs nach einem Monat aus dem System gelöscht werden. Würde auch die Ressourcen schonen. @SebaDro Was meinst du?

SebaDro commented 4 years ago

Systemintern würde ich die Jobs nur ungern nach einer bestimmten Zeit automatisch löschen lassen. Das würde uns die Möglichkeit nehmen, eine Art Job History zu führen. Ressourcentechnisch ist das auch nicht weiter kritisch, da intern für die Speicherung Elasticsearch eingesetzt wird, was ja darauf ausgelegt ist große Mengen an Dokumenten zu verwalten. Da ist es mit unseren wenigen Jobs eher unterfordert. Ein Filtering sollte daher lediglich clientseitig oder über die API vorgenommen werden. Die schnellste Lösung wäre daher aktuell das clientseitige Filtering. Per default können ja, wie @VKirstein vorgeschlagen hat, erst einmal nur die fehlgeschlagenen Jobs des letzten Monats in der Übersicht mitgeführt werden.

imkeines commented 4 years ago

Alles klar! Also dann filtere ich bereits im Request nach Status und Datum, sodass keine Jobs angezeigt werden, die fehlgeschlagen sind und deren Ausführung bereits ein Monat zurückliegt. So müsste es klappen.

SebaDro commented 4 years ago

Wurde umgesetzt mit 863e5c5