Files
computer-playbook/roles/web-app-jellyfin/meta/services.yml
kevinveenbirkenbachandClaude Opus 5 30d8671c39 refactor(mcp): let the sidecar entry be the switch, not the topic
Thirteen of sixteen MCP sidecar entries carried no enabled at all, so
collect_role_resources fell back to _looks_like_container and billed every
one of them as running. Three roles already gated theirs on mcp.enabled;
the rest now do the same, gitea twice because it is the only role with a
vendor container behind the adapter.

The fifteen adapter roles then read services.<key>.enabled instead of
mcp.enabled, so the compose block and the task gates follow the services
entry rather than running beside it on a second path. The six plugin and
native roles keep reading the topic: they ship no sidecar entry to point at.

The three-level resolution is not new. KEYCLOAK_LOGOUT_PANEL_ENABLED has
the same shape and depth and gates a task the same way, and the same value
reaches JAVASCRIPT_SERVICE_ENABLED, where service-gating.js throws on
anything but "true" or "false" — an unresolved chain would have been
killing keycloak's Playwright run since 575a5a87ac.

This does not change what the resource model counts: _is_enabled reads the
unrendered Jinja and still treats it as on. What it buys is one switch
instead of two, and a declaration that matches it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-01 17:42:33 +02:00

118 lines
4.3 KiB
YAML

---
# nocheck: seaweedfs-required - Jellyfin stores its library on a dedicated media volume and metadata in internal SQLite under {{ lookup('volume', 'web-app-jellyfin', 'jellyfin_config').target }}; it has no S3/object-store surface.
sso:
bond: 1
enabled: "{{ 'web-app-keycloak' in group_names }}"
shared: "{{ 'web-app-keycloak' in group_names }}"
flavor: oidc
ldap:
bond: 1
enabled: "{{ 'svc-db-openldap' in group_names }}"
shared: "{{ 'svc-db-openldap' in group_names }}"
logout:
bond: 1
enabled: "{{ 'web-svc-logout' in group_names }}"
shared: "{{ 'web-svc-logout' in group_names }}"
dashboard:
bond: 1
enabled: "{{ 'web-app-dashboard' in group_names }}"
shared: "{{ 'web-app-dashboard' in group_names }}"
matomo:
bond: 1
enabled: "{{ 'web-app-matomo' in group_names }}"
shared: "{{ 'web-app-matomo' in group_names }}"
css:
bond: 1
enabled: "{{ 'web-svc-css' in group_names }}"
shared: "{{ 'web-svc-css' in group_names }}"
prometheus:
bond: 1
enabled: "{{ 'web-app-prometheus' in group_names }}"
shared: "{{ 'web-app-prometheus' in group_names }}"
# nocheck: playwright-service-flag self-provider
jellyfin:
enabled: true
shared: true
bond: 1
modes:
compose:
enabled: true
swarm:
enabled: true
cpus: 2.0
mem_reservation: 1g
mem_limit: 3g
pids_limit: 4096
min_storage: 890MB
image: jellyfin/jellyfin
version: "10.11.11"
backup:
no_stop_required: true
# nocheck: single-replica Jellyfin persists all state in embedded SQLite under the shared {{ lookup('volume', 'web-app-jellyfin', 'jellyfin_config').target }} volume; concurrent replicas corrupt the database (SQLite disk I/O error, malformed image in CI) and upstream has no multi-instance support
replicas: 1
name: jellyfin
ports:
internal:
http: 8096
local:
http: 8088
healthcheck:
flavor: curl
path: health
run_after:
- web-app-keycloak
- svc-db-openldap
lifecycle: beta
# nocheck: playwright-service-flag
# nocheck: variants-coverage — sso-variant-tor requires the onion on in every variant, so the false polarity has no variant left to live in
tor:
bond: 0.5
enabled: "{{ 'svc-net-tor' in group_names }}"
shared: true # nocheck: dynamic-flag
# nocheck: playwright-service-flag, dynamic-flag infrastructure backup consumer
container_backup: # nocheck: bond-baseline backup host joins outside the variant topology
bond: 1
enabled: "{{ 'svc-bkp-volume-2-local' in group_names }}"
shared: true
# nocheck: playwright-service-flag internal adapter sidecar, covered by the role's MCP guest spec
# nocheck: dockerfile-custom the Dockerfile is owned by svc-ai-mcp-adapter and staged per instance, so every adapter-backed provider shares one audited build
# nocheck: dynamic-flag the sidecar tracks this role's own mcp flag, not another role's presence; a group_names expression would decide its exposure from an unrelated deployment
jellyfinmcp:
enabled: "{{ lookup('config', 'web-app-jellyfin', 'mcp.enabled') | bool }}"
shared: false
image: python
# nocheck: docker-version base of the self-built stdlib adapter, not the served application
version: "3.13.15-slim"
custom: true
name: jellyfinmcp
cpus: "0.25"
mem_reservation: 16m
mem_limit: 24m
pids_limit: 64
ports:
internal:
http: 8080
# nocheck: playwright-service-flag MCP pairing is proven by the role's own MCP spec, not by a per-consumer gate
openwebui:
bond: 0.5
enabled: "{{ 'web-app-openwebui' in group_names }}"
shared: "{{ 'web-app-openwebui' in group_names }}"
# nocheck: playwright-service-flag MCP pairing is proven by the role's own MCP spec, not by a per-consumer gate
hermes:
bond: 0.5
enabled: "{{ 'web-app-hermes' in group_names }}"
shared: "{{ 'web-app-hermes' in group_names }}"
# nocheck: playwright-service-flag MCP pairing is proven by the role's own MCP spec, not by a per-consumer gate
openclaw:
bond: 0.5
enabled: "{{ 'web-app-openclaw' in group_names }}"
shared: "{{ 'web-app-openclaw' in group_names }}"
# nocheck: playwright-service-flag MCP pairing is proven by the role's own MCP spec, not by a per-consumer gate
# nocheck: dynamic-flag the entry refuses this client, so the link is off on every host and no group_names gate can decide it
flowise:
enabled: false
shared: false
mcp_consumer: false