News

Update zu Open-Source-Projekt Yaook

Wie üblich möchten wir euch auch in der dritten Ausgabe unseres Newsletters die wichtigsten aktuellen Funktionen, Fehlerbehebungen und Updates rund um unser Open-Source-Projekt Yaook hervorheben und einen Ausblick auf die zukünftige Richtung des Projekts geben.

Yaook ist ein Open Source Projekt, das aus drei Teilprojekten besteht: Yaook/K8s, Yaook/Operator und Yaook/Baremetal. Für eine bessere Übersichtlichkeit haben wir euch nachfolgend alle Neuerungen gemäß dieser Unterteilung aufgeschlüsselt.

Features:

Yaook/K8s:

• Helmify Thanos: Es wird nun das Bitnami Helm-Chart verwendet, um Thanos einzurichten. Dadurch kann der derzeit verwendete JSONnet-Code entfernt und die Codebasis vereinfachen werden. Es wird die Version 12.13.3 als default Thanos Helm-Chart verwendet. Diese Helm-Chart Variante ersetzt in naher Zukunft das zuvor verwendete Thanos_v1.

• Thanos_v2: Es wurden Metriken aktiviert und der veraltete ServiceMonitor entfernt.

• Terraform nutzt nun als default Image das „Ubuntu 22.04 LTS“.

• Neu ist die Unterstützung für Kubernetes v1.26. Die Versionen der Komponenten, die der Kubernetes-Rolle zugeordnet sind, wurden aktualisiert, um auf dem neuesten Stand zu sein. Weiterhin wird die Migration auf den calico Tigera Operator, bei Upgrades auf Kubernetes v1.26, erzwungen. Dieser angekündigte Schritt ist notwendig, um die manifestbasierte Installationsmethode irgendwann loszuwerden, bzw. wenn die Unterstützung für Kubernetes v1.25 eingestellt wird.

• snapshot-controller: Eine Basis für die Unterstützung zukünftiger Versionen des Volume Snapshot Controllers. Die aktuelle Version wird der konfigurierten Kubernetes-Version in der k8s-config-Rolle zugeordnet und auch bei Kubernetes-Upgrades aktualisiert

• NodeSelector wurde zum Tigera-Operator hinzugefügt. Da der Tigera-Operator eine Systemkomponente ist, wurde sichergestellt, dass er auf der „control plane“ erzeugt wird, sodass er nicht durch „worker node pressure“ oder ähnlichem verdrängt werden kann. Dies ist vor allem deshalb notwendig, weil der Helm-Chart es derzeit nicht erlaubt, eine PriorityClass zu konfigurieren.

• Ab sofort nutzen wir „towncrier“ zur halbautomatischen Dokumentation und Ankündigung von Releasenotes. Es dient auch dazu, um Merge-Konflikte beim manuellen Editieren des CHANGELOGs zu verhindern. Wenn ihr Entwickler seid, schaut euch gern den Coding Guide für weitere Informationen an. 

• Nix-Paketmanager: Nix ist ein deklarativer Paketmanager, der NixOS unterstützt, aber auch als zusätzlicher Paketmanager auf jeder anderen Distribution installiert werden kann. Ein flake.nix-File wurde zum Projekt hinzugefügt, der alle notwendigen Abhängigkeiten referenziert, die an bestimmte Versionen gebunden sind.

• „flake.nix“ und „poetry“ bekommen pre-commit-Hooks, die zusätzlich zu „direnv“ für ein Autoinstall/-setup hinzugefügt wurden. Somit hat das .envrc-File die Möglichkeit automatisch eine isolierte Python-Umgebung (venv) beim Betreten und Aktualisieren des Cluster-Repositorys (yk8s; Yaook-Kubernetes) zu laden. Zudem wurde das requirements.txt-File (python) durch poetry (pyproject.toml) ersetzt, um 3th party Library-Versionen zu „pinnen“. Poetry erlaubt es, deklarativ Python-Abhängigkeiten zu setzten und damit Versionen auch festzu“pinnen“. Somit kann sichergestellt werden, dass Inkonsistenzen zwischen individuellen Entwicklungsumgebungen reduziert werden. Die Abhängigkeiten sind in der pyproject.toml-Datei gespeichert und über eine poetry.lock-Datei „angepinnt“. 

• Die aktuelle ’nix_direnv‘ wird geladen (sourced) wenn „flake“ (Nix-Paketmanager) verwendet wird. Dies sorgt dafür, das Betreten und Laden der Umgebung erheblich zu beschleunigen.

• Es wird nun rook v1.8.10 unterstützt. Das Update kann gestartet werden, indem die Version in der config.toml auf „version=1.8.10“ gesetzt wird und dann der Befehl auf der Kommandozeile: ‚MANAGED_K8S_RELEASE_THE_KRAKEN=true AFLAGS=“–diff –tags mk8s-sl/rook“ managed-k8s/actions/apply-stage4.sh‘ ausgeführt wird.

• passwordstore (pass) wurde durch HashiCorp Vault ersetzt. Insbesondere werden Vault-Funktionen verwendet, um die PKI-Zertifikate besser zu verwalten als nur den privaten Schlüssel an einer beliebigen Stelle zu veröffentlichen. Alle bekannten bestehenden Verwendungen von Geheimnissen („secrets“) oder Berechtigungsnachweisen („credentials“) wurden nach Vault verschoben. Ein Migrationsskript für bestehende Anwendungen wird zur Verfügung gestellt ebenso wie eine Dokumentation über Vault im Allgemeinen und diese Verwendung von Vault im Besonderen. Die Kompatibilität mit Metal-Controller ist nur teilweise gegeben, hier sind Änderungen erforderlich.

• Wireguard Link MTU (Maximum Transmission Unit): Die Umgebungsvariable für die MTU des Wireguard-Links wurde festgelegt: In einigen Fällen muss die MTU für die Wireguard-Verbindung separat eingestellt werden, damit der Tunnel ordnungsgemäß funktioniert. Daher gibt es nun eine Umgebungsvariable für die MTU.

• rook_v2: Unterstützung für Bare-Metal-Konfigurationen hinzugefügt.

  • default Helm-Chart Version ist nun v1.11.8

  • es wird kein Marko für resource limits/requests verwendet

  • kleine Pausen vor einem „upgrade checks“, dies gibt dem Operator Zeit ein Upgrade zu starten.

  • Prometheus-Rules nur erstellen, wenn Monitoring aktiviert ist

  • Rook-Chart und Ceph-Versionen sind nun unabhängig; der Code für jeden neuen Rook Helm-Chart muss nun nicht mehr anpasst werden. Es ist jedoch empfehlenswert die Releasenotes vorher zu lesen.

• Neues .envrc-Template. Vorlage für .envrc geändert, um nur noch clusterspezifische Variablen zu enthalten und die benutzerspezifischen Variablen aus verschiedenen Quellen einzubinden.

Yaook/Operator:

• Umstellung auf neue Lizenz-/Abhängigkeitsscans: Die alte Lizenzüberprüfung von Gitlab ist veraltet und der Job schlägt fehl. Der Abhängigkeitsscan verwendet Python 3.10, das ist die neueste unterstützte Python-Version.

• Persistente libvirt/qemu-Protokolle werden nun unterstützt.

• OpenStack Releases „zed“ und „antelope“ für Glance

• Implementierung des „Eviction managers“, um die Auswirkungen eines defekten Hypervisors zu minimieren. Es wird ein Kubernetes-Pod erstellt, der überwacht, ob alle Ressourcen für Nova Compute noch verfügbar sind. Wenn ein Knoten ausfällt, initiiert der Pod eine Räumung (eviction) und entfernt die laufenden Aufgaben (evicts). Anschließend setzt er den betroffenen Knoten in den ‚Ironic Off‘-Modus.

• Neuer Zustand im NovaDeployment: In der Nova-Bereitstellung wird ein neuer Zustand implementiert. Dieser Zustand implementiert einen „Eviction-Manager“. Der „Eviction-Manager“ überwacht die Nova-API, um eine Liste der Hypervisoren oder Compute-Services abzurufen. Wenn die Nova-API einen Hypervisor als ausgefallen markiert, löst der „Eviction-Manager“ einen Räumungsvorgang aus. Um die Räumung von Knoten zu verhindern, die tatsächlich gesund sind, aufgrund einer Netzwerkpartition oder eines Ausfalls der Kontrollplane, wird eine Schwelle implementiert, die die Räumung verhindert, wenn zu viele Hypervisoren gleichzeitig ausgefallen sind.

Yaook/Baremetal:

• Hinzufügen einer dritten Deployment-Option, um das generische Erstellen von base.sh zu ermöglichen. Die Optionen:

  1. base.sh -> Standart von yaook/k8s

  2. „keine“ -> base.sh ist leer

  3. „custom base.sh“ -> basierend auf einem Pfad, der auf eine Datei verweist. Derzeit ist es nur möglich, Nodes mit Kubernetes bereitzustellen. Dies ermöglicht es, in Netbox festzulegen, auf welchem Knoten kein K8s ausgerollt werden soll.

• Implementierung einer Lösung für den Fall, dass ein Gerät über keine IPMI (Intelligent Platform Management Interface)-Funktionalität verfügt. In Fällen, in denen ein Node keine Inband-IPMI-Funktionalität aufweist, muss Yaook mit dieser Situation umgehen können. In diesem Szenario verwendet Yaook die über Dynamic Domain Name System (DDNS) registrierte BMC (Baseboard Management Controller)-Adresse zusammen mit der Seriennummer des Nodes, um das Fehlen von IPMI auszugleichen.

Fixes:

Yaook/K8s:

• Objektbereinigung während der Thanos-Migration: Einführung einer zusätzlichen Migrations-Sicherungsaufgabe, die überprüft, ob die Migration bereits erfolgt ist.

• IPsec: Das Benachrichtigungsskript mit der richtigen Dateierweiterung bereitstellen. Dies behebt das Problem, dass das Keepalived-Notifier.sh-Skript nach .sh-Dateien sucht, während Yaook das Template 10-swanctl-notify.sh.j2 mit der .j2-Erweiterung bereitstellt, was zu Ausfällen führt, wenn die Keepalived-Instanz auf dem primären Gateway ausfällt.

• thanos_v2: Fehlerbehebung beim „scheduling key templating“

• monitoring: Fehlerbehebung für fehlende monitoring_scheduling_key-Variable

• containerd: Fehlerbehebung für fehlende node_has_gpu Variable

• Fehlerbehebung: Nicht-GPU-Cluster in Nicht-GPU-Clustern würden die Rollen ‚containerd‘ und ‚kubeadm-join‘ aufgrund der nicht definierten Variable ‚has_gpu‘ fehlschlagen. Dieser Fix ändert die Reihenfolge der Bedingung, sodass ‚has_gpu‘ nur überprüft wird, wenn die GPU-Unterstützung für den Cluster aktiviert ist. Diese Änderung kann als eine Art Workaround für einen Fehler in Ansible angesehen werden. Normalerweise würde die Variable ‚has_gpu‘ in einer Abhängigkeit beider Rollen gesetzt, aber Ansible überspringt Abhängigkeiten, wenn sie bereits zuvor im Play übersprungen wurden.

• Fehlerbehebung im vault.sh-Script: Das Skript wird beendet, wenn die Datei ‚config.hcl‘ bereits vorhanden ist. Diese Korrektur wurde aufgrund einer Änderung im Verhalten der ‚–no-clobber‘-Option in Coreutils Version 9.2 notwendig.

• Standardmäßig sind die VRRP-Prioritäten („Virtual Router Redundancy Protocol.“) für Space nun weiter voneinander entfernt. Diese Anpassung erfolgt, um die Wahrscheinlichkeit von Wettlaufbedingungen (race-conditions) zu verringern, wenn zwei Knoten gleichzeitig versuchen, die Aufgaben eines ausgefallenen Primärknotens zu übernehmen. Solche gleichzeitigen Übernahmen könnten in bestimmten Randfällen zu Serviceunterbrechungen führen.

• Volume Snapshot CRDs wurden erstellt: Die Erstellung von Volume-Snapshots erfordert Volume-Snapshot CRDs und einen Snapshot-Controller, die zuvor fehlten, aber jetzt bereitgestellt wurden.

• Entfernen von Docker-Resten: Die Unterstützung für Docker wurde zusammen mit Kubernetes-Versionen unter 1.24 entfernt. Einige Teile des Codes waren jedoch immer noch von der unnötigen Variable „container_runtime“ abhängig. Diese Änderung entfernt die Verwendung dieser Variable im gesamten Code und löscht auch die Dokumentation zur Migration von Docker zu Containerd.

• Behebung von Vault für Cluster ohne Prometheus: Zuvor versuchte die Vault-Rolle immer, ServiceMonitors zu erstellen, die das CRD von Prometheus erforderten. Mit diesem Commit wird die Erstellung von ServiceMonitors nun davon abhängig gemacht, ob die Überwachung aktiviert ist oder nicht.

• Behebung von Rook bei Unterscheidung von OpenStack: Standardwerte gelten nun nur noch für Cluster, die auf OpenStack laufen und Cinder CSI als Speicherklassen verwenden. Diese Konfiguration wird für Cluster auf Bare-Metal-Systemen optional gemacht.

• IPsec: Die Passwordstore-Rolle wird nur dann eingefügt, wenn IPsec aktiviert ist. IPsec wurde noch nicht vollständig auf Vault migriert und ist immer noch von der Passwordstore-Rolle abhängig. Wenn IPsec nicht verwendet wird, ist die Initialisierung eines Passwort-Speichers nicht erforderlich. Dieser Commit löst dieses Problem, indem die Rolle über include_role eingefügt wird, anstelle davon, dass sie eine Abhängigkeit ist.

• Rook: Eine Korrektur wird bei der Iteration von gemeinsamen Überwachungsetiketten vorgenommen. Das Standardformat muss ein Wörterbuch sein, nicht ein Array. Die vorherige Bedingung führte zu Fehlern beim Iterieren über die Liste der gemeinsamen Überwachungsetiketten, wenn das Standardformat verwendet wurde, da Elemente für Arrays nicht verfügbar waren.

Yaook/Operator:

• Behebung: Entfernen von ClusterIP für OVN vSwitchd: Der ClusterIP von OVS-vswitchd führte dazu, dass Umgebungsvariablen in allen Pods generiert wurden. In großen Umgebungen verlangsamte dies die Bash und beeinträchtigte dadurch Liveness- und Readiness-Probes. Das Problem wird im Detail in diesem Kubernetes-Issue beschrieben.

• Behebung des OVSDB postStart-Hooks: Der OVSDB postStart-Hook hatte zuvor eine Zeitbegrenzung von 10 Sekunden für den Start der OVSDB. Diese Begrenzung wurde an den Wert der Liveness-Probe angepasst, um der OVSDB mehr Zeit für die Initialisierung zu geben. Die Zeitbegrenzung wird aus Sicherheitsgründen auf 2 Minuten erhöht.

• Behebung des Keystone-Cache-Löschens: Diese Behebung betrifft ein Problem, bei dem eine Ausnahme ausgelöst wurde, wenn ein paralleler Ausführungsprozess versuchte, einen Eintrag zu löschen, der bereits entfernt worden war.

• Rückport des Speicherleck-Fixes aus der Upstream-Quelle: Dies ist ein Rückport oder Monkey-Patch für einen Speicherleck-Fix (https://review.opendev.org/c/openstack/openstacksdk/+/890781). Da OpenStackSDK nur selten neue Versionen veröffentlicht, wurde dieser Patch angewendet, um das Speicherleck zu beheben.

• Erhöhung des Schwellenwerts für die Liveness-Probe des OVSDB bei den Agents: Eine Änderung würde den OVSDB nach dessen Neustart löschen. Wenn jedoch Container aufgrund von Liveness-Probes neu gestartet wurden, würde dies die Verbindungen zu laufenden virtuellen Maschinen (VMs) unterbrechen. Um dies zu verhindern, wird ein hoher Schwellenwert festgelegt, sodass das Beenden des Containers nur bei einem tatsächlichen Problem erfolgt.

• Behebung: Langsamer Upload von Glance-Images: Aufgrund eines Updates auf Python 3.8 und Debian änderte sich der Speicherort des Truststores, was sich auf die Upload-Geschwindigkeit von Glance-Images auswirkte. Diese Behebung aktualisiert das Einbinden der CA-Zertifikate, um das Problem zu lösen.

Yaook/Baremetal:

• Behebung: Entfernen von Zeilenumbrüchen aus der letzten Zeile von Kommentaren: Diese Behebung behandelt ein Problem, bei dem Zeilenumbrüche in der letzten Zeile von Kommentaren vorhanden waren. Diese Zeilenumbrüche könnten, wenn sie an Netbox gesendet werden, zu endlosen Schleifen führen, in denen derselbe Kommentar in jeder Iteration erneut geschrieben wird. Netbox würde die Zeilenumbrüche sowieso entfernen, was zu unnötigen API-Aufrufen führen würde.

• Richtiges Widerrufen des Vault-Authentifizierungstokens: Diese Änderung stellt sicher, dass der Vault-Authentifizierungstoken korrekt widerrufen wird. Zuvor führte der Code zu Ausnahmen, die den Zugriff auf Vault für den Metal-Controller störten, insbesondere nach dem Upgrade der ‚hvac‘-Bibliothek auf Version 0.11.2. Die relevante Dokumentation für die Methode ‚Token.revoke_self‘ finden Sie hier.

Updates:

Verbesserungen der Dokumentation: Wir haben die Projektdokumentation weiter verbessert und sie umfassender, zugänglicher und benutzerfreundlicher gemacht. Zudem hat die Dokumentation einen ausführlichen User-Guide bekommen, der die Konzepte von Yaook näher beleuchtet.

Yaook/K8s:

• Erhöhung der Prometheus-Stack-Version auf 48.1.1

• Erhöhung der Prometheus-Adapter-Version auf 4.2.0

• Anpassung von vault.sh für den Einsatz mit Rootless Docker/Podman: Das Skript ‚vault.sh‘ ist so konzipiert, dass es Container unter dem aktuellen Benutzer ausführt, um sicherzustellen, dass die Dateieigentümerschaft im Verzeichnis ‚./vault/‘ mit dem aktuellen Benutzer übereinstimmt. Dieser Ansatz funktioniert jedoch nicht in Rootless-Umgebungen, in denen Benutzer-IDs (UIDs) innerhalb des Containers auf einen Sub-UID-Bereich abgebildet werden. Mit diesem Commit wird eine neue benutzerspezifische Umgebungsvariable, ‚VAULT_IN_DOCKER_USE_ROOTLESS,‘ eingeführt. Wenn sie auf ‚true‘ gesetzt ist, führt ‚vault.sh‘ vor dem Start des Vault-Containers einen ‚chown‘-Job aus, um die Dateiberechtigungen anzupassen. Es wird auch ein Standardwert für ‚VAULT_IN_DOCKER_USE_ROOTLESS‘ hinzugefügt, um zu verhindern, dass ‚vault.sh‘ fehlschlägt, wenn die Variable nicht explizit gesetzt wird.

• Monitoring: Hinzufügen von Unterstützung für Upgrades auf > v46: Diese Änderung fügt der Überwachungseinrichtung Unterstützung für Upgrades auf Versionen höher als v46 hinzu. In Version v46 wurden neue benutzerdefinierte Ressourcendefinitionen (CRDs) eingeführt, die während Upgrades berücksichtigt werden müssen. Der Commit stellt sicher, dass CRDs bei allen wichtigen Versionsschritten während der Upgrades angewendet werden, um den Prozess zu vereinfachen.

• Rook: Hinzufügen von Unterstützung für beliebige Versionen und Bare-Metal-Umgebungen: Es wird Unterstützung für beliebige Versionen und Bare-Metal-Umgebungen in Rook, einer Plattform für die Speicherorchestrierung, hinzugefügt.

• Neustart der nvdp-Pods bei Kubernetes-Upgrades: Der ’nvdp‘ (NVIDIA Validation Daemon Process) markiert eine GPU als nicht funktionsfähig während ’systemctl‘-Neustarts und nachfolgender ‚kubelet‘-Neustarts. Dies wird als Fehler von ’nvdp‘ betrachtet. Die Pods, die ’nvdp‘ hosten, schlagen nicht fehl, aber die betroffene GPU wird unbrauchbar. Dieses Problem tritt während der Kubernetes-Upgrades auf, daher ist es notwendig, jeden ’nvdp‘-Pod auf Kubernetes-Knoten mit GPUs vor dem Aufheben der Cordon-Beschränkung neu zu starten. Dies stellt sicher, dass die Auswirkungen auf Workloads minimal sind.

• Veraltete monitoring_v1-Rolle entfernt: Die monitoring_v1-Rolle hat die Prometheus-Stack-Bereitstellung über JSONnet-Magie durchgeführt. Das war die Standardinstallationsmethode in der Vergangenheit. Jetzt haben wir Helm, der einen weitaus besseren Job macht.

Yaook/Operator

• Ein neuer Abschnitt in der Dokumentation „User Guide“ https://docs.yaook.cloud/handbook/user-guide.html

• Zwischenspeichern von Keystone-Zugangsdaten: Keystone-Zugangsdaten werden intensiv im Keystone Resource Operator verwendet. In den meisten Fällen handelt es sich tatsächlich immer um dieselben Keystone-Zugangsdaten, da sie sich auf dieselbe Keystone-Bereitstellung beziehen. Um die Effizienz zu steigern, werden diese Zugangsdaten nun optimistisch zwischengespeichert. Im Falle einer Ausnahme werden die Zwischenspeicher gelöscht. Diese Zwischenspeicherstrategie soll die Abgleichzeiten verbessern, kann jedoch dazu führen, dass eine geringe Anzahl von Keystone-Ressourcen den Zustand „BackingOff“ aufweist, wenn sich die Zugangsdaten ändern.

• Optimierung von _labels in ForeignResourceDependency: Somit ist es möglich, den Aufruf an die Kubernetes-API zu vermeiden.

• ceilometer-agent-compute ist nun optional: Wenn er nicht benötigt wird, ist es nicht mehr erforderlich, über alle Knoten zu iterieren. Diese Änderung ist besonders vorteilhaft, wenn es viele Berechnungsknoten gibt, da sie die Verarbeitungszeit reduziert, ohne die Funktionalität einzuschränken.

Yaook/Baremetal:

• Hinzufügen eines Konfigurationsparameters für das Abgleichsintervall: Das standardmäßige Abgleichsintervall kann in größeren Umgebungen die Netbox sehr belasten. Diese Ergänzung bietet die Möglichkeit, das Intervall über eine Umgebungsvariable zu konfigurieren.

Ausblick:

Mit Blick auf die Zukunft zielt das Yaook-Projekt darauf ab, mehrere wichtige Herausforderungen anzugehen und aufregende neue Funktionen zu implementieren.

Der bevorstehende Core-Splitt im yaook/k8s Projekt wird weiter vorbereitet und erste Umsetzungen sind bereits angelaufen.

• Upgrade-Pfad für neuere OpenStack-/OVN-Releases: Wir arbeiten aktiv an der Entwicklung eines nahtlosen Upgrade-Pfads für die neuesten OpenStack- und OVN-Releases, um sicherzustellen, dass Benutzer mühelos über die neuesten Entwicklungen auf dem Laufenden bleiben können.

• Stabilität von OVN: Wir sind bestrebt, die Stabilität der OVN-Komponente weiter zu verbessern, wobei wir uns auf die Beseitigung potenzieller Probleme und die Verbesserung der Gesamtleistung konzentrieren.

• Node lifecycle operator für Updates: Um reibungslosere Updates und Wartung zu ermöglichen, prüfen wir die Entwicklung eines Node lifecycle operators. Dieser Operator würde den Prozess der Neuinstallation von Knoten während Updates automatisieren und so die Abläufe für Administratoren optimieren.

• Release-Management: Wir arbeiten derzeit daran, eine robuste Routine, einen Workflow und Tools für das Release-Management des Projekts zu etablieren. Dazu gehört die Implementierung automatisierter Versionshinweise und Dokumentationsaktualisierungen. Da Yaook/K8s in dieser Hinsicht relativ neu ist, werden wir es als „Spielwiese“ nutzen, um zu experimentieren und einen geeigneten Workflow zu finden, der später auf andere Projektkomponenten angewendet werden kann.

• Weiterentwicklung des Yaook/K8s Teilprojekts, um die Integration mit weiteren Kubernetes-Features und Tools zu verbessern.

• Erweiterung der Yaook/Operator-Funktionalität, um die Automatisierung von Routineaufgaben und die Verbesserung der Systemleistung zu ermöglichen.

• Fortsetzung der Arbeit am Yaook/Baremetal-Projekt, um die Unterstützung für verschiedene Hardware- und Infrastrukturplattformen zu erweitern.

• Verbesserung der Dokumentation und der Benutzerfreundlichkeit des gesamten Yaook-Projekts, um die Einführung und den Einsatz für Entwickler und Administratoren zu erleichtern.

Wir freuen uns über die Fortschritte, die im Open-Source-Projekt Yaook erzielt wurden, und arbeiten weiter an innovativen Funktionen.

Weitere Updates und Neuigkeiten rund um Yaook erhaltet ihr in zukünftigen Newslettern! Meldet euch also gern nachfolgend an, um keine Updates zu verpassen.

Vielen Dank für eure Unterstützung und euer Interesse an Yaook!