Host mit apply-regel für Dependencies

  • Hallo Zusammen,


    ich habe mir eine Test-Icinga 2 Umgebung aufgebaut und nutze den Director um Icinga 2 zu konfigurieren.
    Hierbei wollte ich dann auch die Host-Dependencies konfigurieren und scheitere daran eine apply-regel auf den Host anzuwenden (siehe http://docs.icinga.org/icinga2…s-apply-custom-attributes) gibt es ein Möglichkeit dies im Director zu tun? Wenn es nicht mit dem Director funktioniert wie kann dies dann gelöst werden?


    Gern auch einen Link zur Doku posten in der dies beschrieben steht. Vielen Dank.


    Gruß Chris

  • Hallo!


    Im Director leider noch nicht - aber macht nichts, einfache Abhängigkeiten sind schnell gemacht, z.B. so:

    Code
    1. apply Dependency "switche" to Host {
    2. parent_host_name = host.vars.parentswitch
    3. ignore_soft_states = false
    4. assign where host.vars.parentswitch
    5. }


    Einfach in einer per Hand angelegten globalen Zone ablegen oder per Fileshipper ausrollen, fertig. Und natürlich die Hostvariable entsprechend füllen.

  • Das ist jetzt länger her.


    Ich finde nur leider im aktuellen Director nichts.


    Auf github gibt es ein Enhancement (Enhancement #11332), das nahe legt, host to host dependencies zu implementieren. Aber die geplante Version ist durchgestrichen und seit Februar hat keiner mehr drauf geantwortet.


    Gibt es da was neues? Habe ich was übersehen?


    Ich bräuchte das, für >1000 Hosts, und ich habe keine Lust, das parallel zum Director manuell zu pflegen. Im Moment habe ich die Parents mal in einer Host-Variable abgelegt, aber ich möchte bspw. nicht x Notifications bekommen, wenn ein zentraler Switch ausfällt.

  • Hallo,


    ich habe mich gerade heute mit dem Thema beschäftigt und konnte leider auch nur den Umweg über den Fileshipper finden.


    Aktuell scheint es wohl noch keine Möglichkeit zu geben Dependencies direkt im Director zu erstellen bzw. bearbeiten zu können.

  • Danke, mcktr. Schade, da war ich nicht nur zu doof, das zu finden... ;) 


    Wenn irgendwer wissen sollte, wann das geplant ist? Fileshipper ist hier keine Option, dagegen ist nagiosql Zucker (wir haben icinga1 produktiv).

  • Oh, klar, gerne, done. Da es auf die letzte Nachfrage keine Antwort gab, habe ich hier geschrieben. Hilfe, hm, hätte ich früher gerne angeboten, aber mit eher kleinen Kindern fehlt die Zeit.

  • Ich bin mir häufig nicht sicher wie ich die Issues kommentieren soll, gerade in so einem Fall wo der letzte Kommentar quasi dieselbe Frage ist, wie ich sie habe. Reicht es dann wenn ich dem Kommentar ein "Thumbs Up" gebe oder soll ich einen weiteren Kommentar hinzufügen? Ich habe in so einem Fall immer die Befürchtung, dass mein Kommentar als quengeln rüberkommt und das will ich ja auch nicht. Daher wie wäre es denn am besten, gerade in so einem Fall wo der letzte Kommentar mit meiner Frage/Anliegen identisch ist?


    Aber nichtsdestotrotz ich werde in Zukunft darauf achten die Issues zu kommentieren :)

  • mcktr, geht mir auch so. Es steckt Zeit und Aufwand von anderen dahinter und grad, wenn man wie ich auf absehbare Zeit wenig beitragen kann... Diesmal war es mir aber egal, ob ich "quengel" oder nicht. Denn solange es das nicht gibt, ist unser icinga2-Umstieg (von icinga mit nagiosql) auf Eis gelegt, wir brauchen unbedingt host dependencies (zu viele Hosts, das wird Mail-DoS ohne) und eine Haupt-Anforderung ist, nur ein Konfigurationstool zu haben. Mein "quengeln" hat nur leider nichts gebracht - 3 Thumbs up und keine Antwort. :( 

  • Es gab vor einiger Zeit mal auf GitHub selbst den Feature-Request, die Kommentare wo nur "+1" drinstand, in ein "thumbs up" umzuwandeln. Das ist bei grösseren Projekten immer wieder schwierig gewesen, weil die Diskussion drunter gelitten hatte. Bei Icinga sehe ich das nicht unbedingt so, da man ja deutlich mehr als ein "+1" reinschreiben kann bzw. auch die Issues nicht unbedingt seitenlang werden.


    Ich selbst kommentiere auch dann und wann Issues, die ich für mich als wichtig erachte. Manches davon ist gefixt worden, anderes implementiert und bei vielen Dingen wartet man auch eine Weile bis es die Zeit erlaubt und es gut wird. Ich hab über die Jahre gelernt, dass rumjammern oder sudern weil irgendwas nicht passiert selten zum Ziel führt. Das vergiftet das Ticket, und der Gegenüber mag mir dann gar ned mehr helfen, sondern sagt nur (gedanklich) "der schon wieder".


    Bei "Kleinscheiss" wie fehlender Doku, oder Code den ich nicht kompilieren muss (aka PHP-Code, wo ein var_dump() und die() dann die Variablen im Browser in hässlich anzeigt) mach ich mir manchmal auch die Mühe, da erst einen Patch zu überlegen, bevor ich nur ein Issue aufmache oder eines kommentiere. Das ist allerdings eine Zeit-Frage (max. 15 min) und auch Erfahrungswerte. Und natürlich ein Quentchen Programmieren, wenngleich ich bei PHP oder Ruby auch mit den Ohren schlackere und Manuals lese. Das ist des Entwicklers Not oder Gebot, je nachdem.


    Ich bin selbst Entwickler, und würde natürlich auch "meine" ganzen offenen Issues gerne mal fixen. Ohne ordentliches Zeit- und Ressourcen-Management endet aber auch das irgendwann im Chaos oder Burnout. Bedenkt auch, wenn es Netways und andere Open-Source-Firmen nicht mehr geben würde, dann gibt es wohl auch niemanden mehr, der untertags Tickets bearbeitet oder Probleme löst. Vieles landet dann in der Freizeit am Abend, und irgendwann ist man dann auch durch damit. Oder auch die vielen Firmen, die ihren Mitarbeitern erlauben, in der Arbeitszeit mitunter Fragen zu beantworten. Oder die Selbständigen, die sich Zeit runterzwicken und das gleiche tun.


    Es ist auch nicht verkehrt, mal zu sagen - "braucht Zeit und Geld, wer machts jetz?". Das führt auf seiten des Users meist zu Frust, ist aber immer noch einen Tacken ehrlicher, als gar nix zu sagen und zu warten bis man die Issues einfach so zumacht.


    In der Summe sollte es immer ein miteinander sein, auch wenn es sehr sehr schwierig ist, immer transparent mit allen zu kommunizieren. Ein kleines "Hi, ich auch" hier, ein "danke, dein Fix funktioniert bei mir" da, und am Ende 2 lachende Gesichter.


    Ich finde den Artikel hier sehr lesenswert, da dieser unter anderem belegt, was man selbst nicht wahrhaben mag - kürzer und organisierter treten, damit es am Ende nicht zum Burnout kommt. Das versuche ich gerade, weswegen ich hier im Forum auch nur manchmal sehr aktiv bin, und dann wieder eine Weile nicht.


    https://nolanlawson.com/2017/0…n-open-source-maintainer/


    Das bedeutet natürlich nicht, dass man in Passivität verfallen sollte. Aber ein bisschen geregelter, und mit Ruhe, und weniger angespannten Erwartungen, so tuts gut. Die Erfahrung zeigt, je mehr du pushed und machst, desto mehr wird von dir erwartet. Und man ist enttäuscht, wenn es dann nicht mehr so ist.


    Abwechslung tut auch gut. Wissen vermitteln, aber nicht die "Oberhand" haben. Das ist zum Teil einer der Gründe, warum mich das Icinga Web 2 Modul von Mikesch so stark interessiert in letzter Zeit.


    In der Summe gesehen ist es sehr wichtig, anhand von Tickets und den "ich hab das Problem auch" oder "ich find dieses Feature cool" eine Vor-Analyse treffen zu können, um das sauber einzuplanen.

    Das hilft mir, wenn ich zu $chef gehe und für dringende Tickets um Zeit nachfrage, und es hilft jedem da draussen, zu sehen, dass man nicht alleine ist. Im Umkehrschluss findet sich so meist schneller der gewünschte Fix, oder Code, und man kommt zusammen. Und wenns mal nicht so ist, wie gesagt - nicht aufgeben, und sich in den Gegenüber hineinversetzen. Welche Hilfe könnte wohl von Nöten sein? Macht es Sinn, persönlich anzuschreiben, oder nervt es ihn/sie nur? Welche anderen Aktivitäten hat die Person sonst so auf GitHub/etc. ... kann ich dort mithelfen und Arbeitslast runternehmen? Oder gar etwas neues dazulernen und meinen ersten Patch in einem Open-Source-Projekt einreichen?

  • Für die, die github nicht beobachten: es gibt da was von mdetrano:

    https://github.com/Icinga/icin…odule-director/issues/132

    Etwas eingeschränkt, aber hat Potential.


    Allerdings habe ich mich vor einer Weile für die Lösung von hroc entschieden, da ich da mit einer Host-Variable und einer einzelnen Regel sämtliche Host-Dependencies abdecke. Und die kriege ich in die Lösung von mdetrano nicht rein. Aber gut, dass es jetzt was gibt.