====== Configuration Management ======

Die folgende Seite ist eine Dokumentation der Diskussion auf dem Geekend 2022. Für Dokumentation zu unserem bundlewrap-repo gucke dir bitte die [[https://github.com/voc/cm/blob/master/bundlewrap/README.md|README im cm-Repo]] an.

===== Aktuelle Situation =====

  * ansible repo von 2013 oder 2014?
  * fühlt sich ungepflegt an
  * langsam
  * questionable procedures
    * bei jedem ansible lauf ein mal alles von voctomix löschen und neu deployen machts langsam und unhandlich
    * anpassungen im laufenden betrieb unmöglich
    * änderungen beim apply unsichtbar in ganz viel rauschen
  * voc2mix wurde drangeflanscht
  * kann bisher im saal nur debian 10
  * viel ist am ansible vorbei konfiguriert
    * firewalls
    * web.c3voc.de incident auf der  
  * rz dinge sind an allen cm vorbei konfiguriert (teilweise in ansbile, teilweise nicht)
    * das Problem war nicht ansible, sondern verschiedene leute machten verschiedene quickfixes ohne dinge nachzuziehen


===== Links ===== 
  * [[https://github.com/voc/cm]]
  * [[https://bundlewrap.org/]]
  * [[https://git.franzi.business/kunsi/bundlewrap]]
    * beispiel bundle für eine node anwendung: [[https://git.franzi.business/kunsi/bundlewrap/src/branch/main/bundles/hedgedoc]]
  * [[https://github.com/ansible/awx]]

===== Vorschlag =====

  * von sophie, hexchen und kunsi
    * alles abbrennen und mit einem frischen, überblickbaren repo ersetzen.
    * saal und rz trennen?
    * bundlewrap statt ansible?
      * es gibt ein proof of concept im cm repo in einem eigenen branch
    * für einen sinnvollen umstieg muss es einen harten cut geben, saalzeug kann in einer woche laufen

===== Ergebnisse =====

  * Wir fangen mit dem Saal an
    * hier ist bundlewrap gut geeignet, da relativ oft neu neugebaut und niedrige einstiegshürde
  * In den Main branch mergen/migrieren
  * Was in bunblewrap gesichert funktioniert, direkt aus ansible löschen
  * rz setup
    * es braucht ein paar leute die das CM pflegen, bzw nach dem event die diffs nachziehen
    * hier können wir mit einer basisrolle anfangen
    * für die vm könnte man mit nixos anfangen
      * für sourcecodes / checkouts kann man die git version festpinnen
    * web / mngt
      * ist alles irgendwie zusammengewachsen, hier kann man nach diensten trennen
      * für quick applications (etwas nodejs/python) braucht man einen ansatz. das muss sehr gut dokumentiert werden
        * fahrplankonverter, datenmerger, ...
      * es ist egal was da läuft, aber es muss mit beispielen dokumentiert werden
  * für jeden service //muss// im wiki stehen was 

===== Todos =====

  * bundlewrap für saal fertigstellen und ausrollen, test auf der MCH (kunsi)
  * hexchen sucht sich nach der MCH mit anderen leuten diensten ansehen und ein paar nixos vorschläge machen 
  * danach: review des vorschlagen