- Yaook - lists.alasca.cloud

New Release Management - release-notes needed for all MRs

by Stefan Hoffmann

Hi yaook-developers, we will merge soon the new release management to yaook[1]. It requires to create release notes for each MR. Temporary link to the docs how to create release notes (when the MR is merged, there will be a static one): [2] Related Issue: [3] [1] https://gitlab.com/yaook/operator/-/merge_requests/2825 [2] https://yaook.gitlab.io/-/operator/-/jobs/12682421941/artifacts/public/deve… [3] https://gitlab.com/yaook/operator/-/issues/490 Best regards Stefan -- Stefan Hoffmann DevOps-Engineer Cloud&Heat Cloud&Heat Technologies GmbH Königsbrücker Straße 96 (Halle 15) | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. [1] Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann [1] Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/

Jan. 12, 2026

Yaook SCS Operator hackathon 2026-02-26, Hamburg - save the date!

by Friedrich Zahn

Hi, the ALASCA-FOCIS team, supported by Dataport, UhuruTec and other community members, is planning a one day hackathon to work on a Yaook SCS Operator that will make it easier to run SCS-IaaS compliant Yaook cloud offerings. Save the date: 2026-02-26 in Hamburg. More details will follow soon, stay tuned! Feel free to get back to me with any questions or suggestions. Best regards Friedrich

Jan. 8, 2026

Broken rolling release 0.20251212.0-rolling.T112342.g9c644a7aea39

by Stefan Hoffmann

Hi, the releases 0.20251212.0-rolling.T112342.g9c644a7aea39 and newer are broken with VM action fails due to service_token_roles_required=true at neutron (and other services). But neutron doesn't has the nova-compute role as allowed service-token-role in it's config[1]. So don't roll it out to your neutron and barbican operator. Currently there is no stable release with this bug. There is already a fix[2] in creation. Best regards Stefan [1] https://gitlab.com/yaook/operator/-/issues/643 [2] https://gitlab.com/yaook/operator/-/merge_requests/3318 -- Stefan Hoffmann DevOps-Engineer Cloud&Heat Cloud&Heat Technologies GmbH Königsbrücker Straße 96 (Halle 15) | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. [1] Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann [1] Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/

Jan. 8, 2026

[Security Advisory] MariaDB replication traffic is send unencrypted between MariaDB instances when using IPv6

by Stefan Hoffmann

Hi, we got informed about a security issue and released a fix for it now. A CVE ID is requested and will be added later. The link to the advisory will change due to that. Temporary link: https://yaook.cloud/security-advisories-cve-2025-xxxxx/ YAOOK Security Advisory for CVE-2025-XXXXX * Date: 2025-12-12 * Affected versions: >=0.20240809.0 <0.20251211.0 * Fixed versions: 0.20251211.0 * Bug report: https://gitlab.com/yaook/operator/-/issues/631 * Patch: https://gitlab.com/-/project/21574229/uploads/6a4f06d3ae63f8ed4657825f864f9… What is CVE-2025-XXXXX and how does it affect YAOOK?CVE-2025-XXXXX describes the issue that MariaDB replication traffic is sent unencrypted between MariaDB instances managed by YAOOK’s infra-operator if the cluster is IPv6-enabled. In 2024, YAOOK gained official support for running inside IPv6-only and dual-stack Kubernetes clusters. For this, various services had to be updated to allow listening on IPv6 sockets in addition to (or instead of) IPv4 sockets. For MariaDB, there exist three communication channels: The normal client/server traffic with MariaDB-compatible clients (such as the OpenStack APIs), the incremental state transfer and online replication traffic (WSREP) and the SST channel (used if, after a restart, the incremental state transfer is not sufficient to bring a replica up-to-date). The WSREP transfer channel is configured through a single MariaDB configuration option called `wsrep-provider-options`. Before the addition of IPv6 support, this option was set up by YAOOK exclusively through the MariaDB configuration file. As value to that single option, one provides the path to the TLS certificates and the listening address of the WSREP channel, formatted as string into in a MariaDB-specific format. When IPv6 support was implemented, the listening address of the WSREP socket had to be changed to `[::]` in order to be able to accept connections from other instances via IPv6. This was implemented by passing an additional `–wsrep-provider-options` command line argument to the MariaDB process [1]. Unfortunately, that overrode the TLS-related options from the configuration file, effectively disabling TLS for the WSREP channel whenever that code path is hit. Is my cluster vulnerable?The affected code path is executed whenever the `status.podIP` field of the MariaDB pod is an IPv6 address. This is the case in IPv6-only clusters and may be the case in dual-stack clusters. If that is the case, TLS encryption of the WSREP channel is disabled, which causes almost all MariaDB contents to be transferred without encryption in transit. Mitigating factors * This vulnerability only affects IPv6-only clusters. * The unencrypted traffic never leaves the Kubernetes service network, which may or may not already be a trusted domain in your security model. UpgradingA new stable release with version 0.20251211.0 has been published. Affected clusters will face a downtime during upgrades, because TLS encryption on the WSREP channel cannot be enabled online. During the upgrade, the highest replica of all databases managed by the infra-operator will enter a Error / CrashLoopBackOff state. At that point, you have to execute the following steps for each separate database instance: 1. `yaookctl pause mysqlservices $name` 2. `kubectl -n yaook scale sts $name-db –replicas=0` 3. Wait for the last database replica to terminate. 4. Optional: `kubectl -n yaook scale sts $name-db –replicas=$n`, where `$n` is the number of replicas you usually have. This may be slightly faster than waiting for the infra-operator to reset the replica count after the next command. 5. `yaookctl unpause mysqlservices $name` During the time the last replica of a database is shut down, the database can, obviously, not serve requests. This will cause HTTP 500 responses from affected API services and may have downstream adverse effects on workloads (such as Kubernetes Cinder CSI providers running inside the cluster). CreditsThis vulnerability was found by Martin Morgenstern and Maximilian Brandt, CLOUD&HEAT Technologies GmbH. [1] implemented by passing an additional `–wsrep-provider-options` command line argument to the MariaDB process https://gitlab.com/yaook/operator/-/commit/21ceaa1375bfd08d5706adfcd74f630f…

Dec. 12, 2025

[yaook][infra-operator] Issue withAMQP custom images

by Stefan Hoffmann

Hi, since the release 0.20251127.0-rolling.T101903.g92875879628b (there is no stable release with this yet, it may be 0.20251204.0 or 0.20251208.0) it's not possible anymore to set custom images for AMQP services. For the most yaook users this is no issue, as all AMQPs are created by other operators. Also normal version overrides still work. But if you want to define a different rabbitmq image (different path than the other yaook images) currently don't work. There is an issue[1] to fix that. [1] https://gitlab.com/yaook/operator/-/issues/633

Dec. 8, 2025