[Bug report] "Apply pending changes" fails with HTTP 500 – Jinja `services is undefined` in avahi minio deploy state

Bug: Avahi MinIO deploy fails with Jinja UndefinedError, blocks all "Apply pending changes" (HTTP 500)

I created this report AI assisted...

Description:

When MinIO is enabled and zeroconf (Avahi) discovery is active, the Avahi deploy state for the MinIO service crashes with a Jinja template error. Because OMV executes pending config changes atomically via the web GUI, this single failure aborts the entire "Apply" operation and returns an HTTP 500 - preventing all pending configuration changes from being applied.

Root cause:

The Salt state file /srv/salt/omv/deploy/avahi/services/minio.sls passes a flat context to the shared Avahi service template, but the template expects a services list.


Current code (minio.sls, lines 33-36):

- context:
    type: "{{ ssl_enabled | yesno('_https,_http') }}._tcp"
    port: {{ config.consoleport }}
    name: "{{ zeroconf_name }}"

Expected by template (template.j2
The template iterates over a services variable:

{%- for service in services %}
    <service>
        <type>{{ service.type }}</type>

Variable services is never defined, resulting in:

jinja2.exceptions.UndefinedError: 'services' is undefined; line 5
salt.exceptions.SaltRenderError: Jinja variable 'services' is undefined

Reproduction steps:

1. Install OMV 8 with the MinIO plugin (openmediavault-k8s / S3)

2. Enable MinIO service in the WebGUI

3. Ensure Avahi/Zeroconf is enabled (default)

4. Trigger "Apply pending changes" from the web GUI or run:

omv-salt deploy run avahi

5. Observe HTTP 500 / Salt render error

Symptom:

• WebGUI banner: "Ausstehende Konfigurationsänderungen" persists indefinitely
• Clicking "Apply" repeatedly returns HTTP 500
• dirtymodules.json accumulates all dirty modules and never gets cleared
• PHP-FPM logs may show OOM kills (heavy deploy cycles on memory-constrained systems)

Fix:

Change the context in /srv/salt/omv/deploy/avahi/services/minio.sls to pass a services list:

diff:
     - context:
-       type: "{{ ssl_enabled | yesno('_https,_http') }}._tcp"
-       port: {{ config.consoleport }}
+       name: "{{ zeroconf_name }}"
+       services:
+         - type: "{{ ssl_enabled | yesno('_https,_http') }}._tcp"
+           port: {{ config.consoleport }}
        name: "{{ zeroconf_name }}"

Verification after patch:

omv-salt deploy run avahi
# Summary should show: Succeeded: 15, Failed: 0

Workaround for affected users:

Apply all pending changes via CLI instead of the WebGUI:

# Deploy each dirty module individually
cat /var/lib/openmediavault/dirtymodules.json | tr -d '[]"' | tr ',' '\n' | while read mod; do
  omv-salt deploy run "$mod" 2>&1 | tail -5
done

# Then clear the dirty list
echo '[]' > /var/lib/openmediavault/dirtymodules.json

Notes:

• The same template.j2 is used by other Avahi service files (smb, ssh, website) which correctly pass the services array - only the MinIO state is inconsistent.
• Bug likely introduced during OMV 8 migration to Salt-based config deployment.