[Git] Ansible-Zweig master gerade ziehen

Die beiden Zweige master und entwicklungszweig von https://github.com/FreiFunkMuenster/ansible-ffms sind inzwischen weit auseinander gelaufen.
Für die tägliche Arbeit nutzen wir nur den Entwicklerzweig. Daher ist zu überlegen ob wir anstelle vieler Merges lieber den Entwicklerzweig direkt zum master umfunktionieren. Dazu würde der aktuelle master umbenannt werden.
Hat jemand etwas dagegen?

@void, @Parad0x, @FanLin, @paulinsche, @descilla, @kgbvax, @MPW, @Fungur

  • Manuelles Mergen
  • Entwicklerzweig zum master machen

0 Teilnehmer

Da ich mich mit Git noch nie wirklich auseinandergesetzt habe, kann und möchte ich nicht beurteilen, was sinnvoller ist. Ergo: Ich enthalte mich.

1 „Gefällt mir“

Zumindest @void hat im master nach dem Fork des Entwicklungszweigs noch viele Änderungen gemacht. Die müssen vor einem Umbenennen unbedingt noch nachgezogen werden. Ich weiß nicht, ob das händisch oder mit git-Unterstützung besser funktioniert.

Der Branch ffservice muss übrigens auch noch mit berücksichtigt werden, da er alles für die neue Service-VM enthält. Er ist ansonsten auf dem Stand von master.

Klingt so als ob das sinnvoll wäre das ihr euch mal generell Gedanken macht wie euer Branch und Merge Konzept aussehen soll und das irgendwo fest haltet.

2 „Gefällt mir“

Ich habe noch mal überlegt und denke jetzt, die beste Herangehensweise wäre wahrscheinlich, ffservice nach master zu mergen (sollte automatisch gehen), und dann den master in den entwicklungszweig zu mergen (mit mehreren Konflikten, die manuell zu lösen sind) und am Ende den entwicklungszweig in den master zu mergen (sollte dann ja wieder automatisch gehen). Ich wäre bereit, das durchzuführen.

Ich habe ffservice nach master gemerged und werde mich jetzt daran versuchen, den master nach entwicklungszweig zu mergen. Falls ihr am entwicklungszweig arbeiten wollt, sagt bitte Bescheid.

1 „Gefällt mir“

Ich habe jetzt master nach entwicklungszweig gemerged (D.h. alle müssen git pull machen, wenn sie nicht noch mal Mergen wollen). Dabei gab es folgende Konflikte, wo ich mir nicht sicher bin:

  • graphite_data_target: 5.9.86.154 oder 10.43.0.12?
  • c1024: server_id: 4 oder 5?
  • c1024: Name des Besitzers?
  • dhcpd.conf: authoritative oder nicht?
  • dhcpd.conf: host badguy noch relavant?
  • In /etc/network/interfaces wurde teils “source /etc/network/interfaces.d/", teils "source /etc/network/interfaces.d/.cnf” eingefügt. Ich hab mich für ersteres entschieden, da es auf den meisten Maschinen konfiguriert ist.

Ich habe nach den Änderungen einige ansible-playbook-Läufe mit --diff --check durchgeführt. Dabei werden eine ganze Menge Kleinigkeiten geändert, die ich jetzt nicht ausrollen möchte. Aber leider sind auch einge Einstellungen auf den Servern nicht so wie in Ansible und ich weiß nicht immer was richtig ist. D.h. wenn das nächste Mal Änderungen anstehen, genau aufpassen.

Folgende Hosts haben wichtige Unterschiede, die nicht aus den Konflikten oben stammen:

  • fanlin: Tunnel zu Rheinland und Gateways in Ansible konfiguriert, bird-Config unterschiedlich
  • des1: Mehr Tunnel zu Gateways in Ansible konfiguriert, bird-Config unterschiedlich
  • c1024: Tunnel-IPs ändern sich weil fanlin-03 hinzukommt.
  • greyworm-02, greyworm-03, greyworm-04, greyworm-05, parad0x-01: Tunnel-IPs ändern sich
  • remue-02, remue-03, remue-04: zusätzliche Tunnel zu c1024 und des1
1 „Gefällt mir“

Vielen Dank für deine Mühe!

Ich denke mal, dass die einfach die neuen Tunnel-Rollen von @descilla noch nicht ausgerollt wurden.

Marcus Scholz / Commander

Immer Authorativ.

Grüße
Matthias

@MWP: Ok, dann habe ich es in Ansible richtig gemacht, aber die Hosts sind falsch konfiguriert:

  • auf c1024 steht Besitzer: Jan-Marten Brüggemann / Commander1024
  • in dhcpd.conf auf den neuen Domänen fehlt authoritative

Letzteres, das funktioniert zwar nur in der legacy Domäne. Das mit 5.9.86.154 ist jedoch nur ein temporärer Hack und sollte daher nicht drin stehen.

4

Habe ich heute Nacht in irgend einen Commit eigentlich rein geschrieben.

Nope. Beachte, dass ich letztens ein feature für static hosts eingebaut habe.

Das soll noch geändert werden. Wir haben uns ein automatisches Verfahren zur IP Vergabe ausgedacht, damit wir nicht immer händisch welche angeben müssen. Das habe ich heute Nacht mal in Ansible umgesetzt. Und testweise auf c1024 ausgerollt, da der noch nirgends angebunden ist. Folglich ändern sich alle IPs. Das muss aber noch geprüft werden, bevor es ausgerollt wird.

Stimmt. Gerade mal bei mir vor dem Zusammenführen nachgesehen, das fehlt.

Nach einigen Aufräumarbeiten und Verbesserungen und Ausrollen auf ca. 20 Servern habe ich den entwicklungszweig nach master gemergt.

Als nächstes sollten wir überlegen, wie wir weiterhin mit den Branches umgehen wollen, damit wir nicht wieder in so eine Situation kommen.

1 „Gefällt mir“