Marathon: Filteroption für Ereignistypen auf GET /v2/events-Endpunkt hinzugefügt

Ich habe gerade gesehen, dass es auch https://github.com/mesosphere/marathon/issues/654 gibt, das noch offen ist.

Verwandt mit #3154

Danke @janisz für das Verlinken der Probleme und auch an @jasongilanfarr für die Kennzeichnung.

Ich denke, ein gutes Beispiel für diese Art der Filterung ist die Facebook Graph API mit ihrer Felderweiterungsfunktion . Damit ist es sogar möglich, das Ergebnis auf verschachtelte Teilfelder (Objekte) zu filtern/definieren.

Eine einfache Abfrage kann beispielsweise so aussehen: https://graph.facebook.com/?id=http :// www.google.com

was dazu führen wird

{
   "og_object": {
      "id": "381702034999",
      "description": "Search the world's information, including webpages, images, videos and more. Google has many special features to help you find exactly what you're looking for.",
      "title": "Google",
      "type": "website",
      "updated_time": "2016-11-17T09:31:49+0000"
   },
   "share": {
      "comment_count": 2,
      "share_count": 39738503
   },
   "id": "http://www.google.com"
}

Verwendet man die Felderweiterung wie https://graph.facebook.com/?fields=og_object {description},share{share_count}&id= http://www.google.com

man erhält stattdessen dies:

{
   "og_object": {
      "description": "Search the world's information, including webpages, images, videos and more. Google has many special features to help you find exactly what you're looking for.",
      "id": "381702034999"
   },
   "share": {
      "share_count": 39738503
   },
   "id": "http://www.google.com"
}

Mir ist bewusst, dass dies den Umfang sogar erweitert, aber meiner Meinung nach wäre es auch sinnvoll, zusätzlich dazu, allgemein nach Ereignistypen filtern zu können.

Ich wollte es vor ein paar Monaten implementieren. Aber ich stieß auf ein Problem damit, es mit der alten Implementierung abwärtskompatibel zu halten. Abonnements werden in ZK gespeichert, daher müssen wir einen Migrationsschritt hinzufügen, um es korrekt zu handhaben.

Jetzt wird es für mich kritisch, weil einige Ereignisse > 8 MB sind.

EDIT: Tut mir leid. Als ich dies schrieb, dachte ich über die Implementierung von HTTP-Ereignissen nach, die in Zookeeper bestehen bleiben.

@janisz Ich denke, das betrifft viele Anwendungen, zum Beispiel sollte marathon-lb auch davon betroffen sein.

Ich habe eine Marathon->Slack-Integration erstellt, und dort bin ich persönlich zuerst darauf gestoßen. Ich mache die Filterung auf der Anwendungsseite, was meiner Meinung nach in Bezug auf CPU- und Netzwerkressourcen ineffektiv ist.

Es kann Anwendungsfälle geben, in denen es sinnvoll wäre, auch nach Feldwerten zu filtern, z. B. wenn eine Anwendung nur auf bestimmte Anwendungsereignisse lauschen möchte, z. B. Statusaktualisierungen eines bestimmten appId .

Vorbereitete Pull-Anfrage für diese Nr. 4671, bisher funktioniert nur die Filterung nach Ereignistyp. Wir können überlegen, ob wir noch etwas brauchen.

Ich habe in Node einen Marathon-Ereignis-Proxy erstellt, der zum Filtern nach Ereignistyp verwendet werden kann, bis dies die native Marathon-Funktionalität ist:

https://github.com/tobilg/marathon-event-proxy

Danke @janisz für die PR und @jasongilanfarr für die Zusammenführung! Das war schnell :-)

Darf ich fragen, in welcher Marathon-Version das enthalten sein wird? Wäre es außerdem sinnvoll, ein weiteres Problem bezüglich der Filterung/Neuformatierung der Ereignisobjekte zu eröffnen (zu https://github.com/mesosphere/marathon/issues/4637#issuecomment-261198914)?

Der aktuelle Plan ist, dies in 1.4 zu veröffentlichen, das in den nächsten Wochen einen RC haben sollte.