FKITDEV-8354 — vuer-release PR #28 supervisor-config dedup (round-2 review)

Resolving Bence’s round-2 review on vuer-release PR #28 (MVM partner migration to the Gen2 lean format). Two “merge this with the supervisor config in the <repo> repository” comments: the vuer_css one was a pure byte-identical duplicate (deleted), the vuer_oss one is an intentional partner override (kept). Includes the reusable mechanism for how supervisor configs reach /etc/supervisor/conf.d/ in vuer-release component images.

PR identity — do not conflate with FKITDEV-8252

TechTeamer/vuer-release PR #28 = feat(FKITDEV-8354): migrate mvm project (branch feature/FKITDEV-8354, base master) — the MVM partner migration (vuer_build → vuer-release Gen2 lean format). This is DISTINCT from PR #31 = feat: ubi10 (FKITDEV-8252, branch feature/FKITDEV-8252-ubi10) — the UBI10 base-image work. Different ticket, different branch, different scope. See FKITDEV-8252.

For Agents

  • Repo: TechTeamer/vuer-release; PR #28; branch feature/FKITDEV-8354; base master; reviewer bencelaszlo.
  • Local worktree: /Users/levander/coding/facekom/vuer-release/.worktrees/FKITDEV-8354.
  • Round-1 review (2026-05-08) already resolved: janus version pins 1.4.1 / cc0fdca8; restored supervisor-stdout plugin (commit 07db225).
  • Round-2 (2026-06-15) = two new comments, both “merge this with the supervisor config in the <repo> repository”.
  • State 2026-06-16: changes made LOCAL & UNSTAGED in the worktree only. NOT committed, NOT pushed. Reply to Bence drafted, NOT posted. User constraint: do not write anything to GitHub.

The two round-2 comments and their resolutions

FileCommentResolution
projects/mvm/components/vuer_css/supervisor_vuer_css_docker.confmerge with vuer_css repo configDELETED — byte-identical duplicate of the vuer_css repo copy. Also removed its COPY … /etc/supervisor/conf.d/ line from projects/mvm/components/vuer_css/Dockerfile.
projects/mvm/components/vuer_oss/supervisor_vuer_oss_docker.confmerge with vuer_oss repo configKEPT — intentional partner override, NOT a duplicate. Merging would regress the round-1 decision.

vuer_css — safe to delete (provably behavior-neutral)

The partner copy was byte-identical to the vuer_css repo’s supervisor_vuer_css_docker.conf, i.e. a pure duplicate. Removing the file + its Dockerfile COPY is safe because the base image’s install/configure-app.sh (lines 16-21) symlinks all $APP_HOME/supervisor*.conf from the extracted source package into /etc/supervisor/conf.d/, and supervisord.conf includes files = /etc/supervisor/conf.d/*.conf. With the redundant COPY gone, the resulting conf.d file set is identical (the source-package conf is symlinked in either way). Behavior-neutral.

vuer_oss — intentional override (the architectural finding)

Compared against the correct baseline

The right baseline is the vuer_oss repo’s MVM source branch origin/chore/FKITDEV-8892-mvm-devel-update-2026-06-01 (blob d6e7843) — NOT plain devel. The partner config is a customization layered on the MVM branch, so diff against that branch.

Aspectvuer_oss repo (MVM branch, blob d6e7843)vuer-release MVM copy
Loggingfile-based (stdout_logfile=/var/log/…)supervisor-stdout eventlistener (stdout_events_enabled=true, stdout_logfile=NONE)
Program count9 programs8 programs
[program:vuer_oss_storage] (node storage.js)presentomitted

Source-verified from the worktree copy (projects/mvm/components/vuer_oss/supervisor_vuer_oss_docker.conf): 8 programs — nginx, redis, vuer_oss, vuer_integration_log, vuer_media, vuer_oss_convert, vuer_cron, vuer_background — every program block uses stdout_events_enabled=true + stdout_logfile=NONE, and there is no [program:vuer_oss_storage].

Why merging it back would be wrong:

  1. The eventlistener apparatus lives ONLY in vuer-release. The trio supervisor_stdout.py + supervisor_stdout_eventlistener.conf + pip install supervisor-stdout (in the Dockerfile) exists only in vuer-release — it is not in the vuer_oss repo at any ref. It is the consumer of the supervisor-stdout plugin Bence asked to RESTORE in round 1 (commit 07db225). Collapsing this config to the repo’s file-logging version (stdout_logfile=/var/log/…) would make that plugin a no-op and regress the round-1 decision.
  2. Dropping vuer_oss_storage is the consistent vuer-release convention. Every partner that carries a vuer_oss supervisor conf in vuer-release omits [program:vuer_oss_storage]: equilor, nusz, polgaribank-facekom, unicredit, unicredit-srb, mvm. So the omission is an intentional, repo-wide convention — not an MVM-specific accident.

Reusable mechanism — how supervisor configs reach conf.d in vuer-release

Two paths into /etc/supervisor/conf.d/ (last-write-wins by filename)

In vuer-release component images a supervisor config lands in /etc/supervisor/conf.d/ via two paths:

  1. install/configure-app.sh symlinks the source package’s supervisor*.conf (the repo’s own conf, baked into the source package).
  2. The partner component Dockerfile COPYs a partner override on top — same filename ⇒ last-write-wins, the override shadows the symlinked repo conf.

supervisord.conf then includes files = /etc/supervisor/conf.d/*.conf.

Decision rule: a partner override is a deletable duplicate only if byte-identical to the repo’s conf (then the COPY is redundant — the symlink already provides it). Otherwise it is an intentional customization and must be kept. → vuer_css = duplicate (deleted); vuer_oss = customization (kept).

State of changes (this session)

Local only — nothing pushed

  • Worktree: /Users/levander/coding/facekom/vuer-release/.worktrees/FKITDEV-8354
  • git status: M projects/mvm/components/vuer_css/Dockerfile, D projects/mvm/components/vuer_css/supervisor_vuer_css_docker.conf
  • vuer_oss conf left untouched (kept by design).
  • Unstaged, NOT committed, NOT pushed. Reply to Bence on the vuer_oss thread drafted but NOT posted. User explicitly said: do not write anything to GitHub.

Round-1 recap (already resolved, 2026-05-08)

  • janus version pins → 1.4.1 / cc0fdca8.
  • Restored the supervisor-stdout plugin (commit 07db225) — this is the plugin the vuer_oss eventlistener config above depends on.