The dotenv generator refuses a passthrough key the SPOT does not
declare, so an unset variable stays an explicit empty rather than a name
nothing owns.
keep_address switches the connection, the user, the key and the ssh
args exactly as the mesh switch does, and leaves ansible_host where it was.
Against the other two transports that isolates the cost of leaving the local
connection from the cost of the tunnel.
The callback truncated its summary, so a deploy's per-task table was
only ever its own top 300. Comparing two transports needs the tasks the
truncation dropped, and 'all' is a value the plugin handles explicitly.
MCP Adapter 0.7.0 for WordPress refuses a request that follows
initialize without the MCP-Protocol-Version header: 'Invalid Request:
MCP-Protocol-Version header is required for a 2025-06-18 session'. The
contract probe never sent it, so the CLI test of web-app-wordpress
failed at tools/list.
The probe now keeps the version the server answers initialize with and
sends it on every later request of the streamable HTTP transport, which
the specification asks of a client since 2025-06-18.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
gitea-mcp-server 1.8.0 is the first release that ships a HEALTHCHECK,
and it is written in shell form for an image that has no shell. Every
probe ends in 'exec: "/bin/sh": no such file or directory', the
container turns unhealthy after three attempts, and Swarm replaces the
task about every 72 seconds, so the service never converges.
The role now declares the probe itself, in exec form and with the port
the sidecar listens on: without it the probe asks 8080 whatever the
server uses. The command took that port from the adapter's entry, it
now reads the sidecar's own.
The adapter waits for a healthy sidecar, so a probe that cannot pass
fails a compose deploy as well and not only a Swarm one.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The pin moved from 4.5.11 to 5.3.0, and the role fitted neither a new
install nor an existing one.
Moodle 5 serves from public/ and routes every other path through
r.php. nginx now uses public/ as its root, hands unknown paths to the
router and passes PATH_INFO for scripts with slash arguments, and
config.php declares the router as configured. The paths the role checks
and writes (version.php, auth, webservice, the OIDC plugin) moved below
public/, the URL of the OIDC plugin stays auth/oidc. The source archive
no longer contains vendor/, so the image installs the Composer
dependencies it declares. The OIDC plugin is pinned to v5.2.1, the
newest release.
An existing site kept its old code: the entrypoint filled the code
volume once and never again. It now records the release it copied and
replaces the tree when the image carries another one, and a new task
runs admin/cli/upgrade.php. Plugins that were installed through the web
interface are not carried over, the README says how to ship them.
A site installed with 5.3 forces login by default, which 4.5 did not,
so its start page answers 303 to the login page and the webserver
health check refused it. The role declares 200 and 303 as the codes
that check accepts: 200 is what an upgraded site keeps answering.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A heap, a cache size or a PHP limit written as a literal drifts away
from the mem_limit its service declares. The lint scans roles/ and
group_vars/ for the known spellings of such parameters and requires
each value to reach lookup('service_memory_mb'), or the Node lookup for
the V8 heap, on its own line or through the variables it reads.
It follows names inside {{ }} and $NAME through the definitions of the
role and of group_vars, reads a command list, a folded scalar and a
wrapped expression as one line, and counts a literal fallback as a
literal. A sidecar snippet has to name its own role as provider.
It knows a list of spellings and layouts. A parameter written another
way is not seen.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
PHP_MEMORY_LIMIT and PHP_OPCACHE_MEMORY_CONSUMPTION were both the host's
RAM divided by 30, read from two keys in meta/services.yml: 533M on a
16 GB host, 2133M on a 64 GB one, beside a container limited to 3g either
way. They are now half and an eighth of that limit through
lookup('service_memory_mb'), which renders 1536M and 384M on every host.
The lookup sits in env.j2 and the two meta keys are gone. It reads the
applications payload, and meta/services.yml is part of that payload, so
a call from there would run back into the render that asked for it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
upload.ini set memory_limit to WORDPRESS_MAX_UPLOAD_SIZE, the same 256M
as upload_max_filesize and post_max_size, so the memory a request may
use depended on how large an upload may be. It is now a quarter of the
service's mem_limit through lookup('service_memory_mb'), which renders
384M beside the 1.5g container. The upload sizes keep their variable.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The Confluence and Jira READMEs said the JVM heap was derived from host
RAM with safe caps. It is 70 % of the service's mem_limit for
JVM_MAXIMUM_MEMORY and 35 % for JVM_MINIMUM_MEMORY, and the caps of the
old filter no longer exist.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The init service received INIT_PHP_MEMORY_LIMIT through an inline
environment block in the compose template. It moves to templates/env.j2,
which the container base hands to every Shopware container as env_file.
Only files/shell/init.sh reads the variable, behind a `:?` guard, so the
other containers seeing it changes nothing.
The lookup names 'init' instead of service_name, which is bound in the
compose template but not in env.j2. The value stays 1024M.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
LDAP_MEM_LIM was a literal 500M beside a 2g container. It is now a
quarter of the service's mem_limit through lookup('service_memory_mb'),
the share the seed command of this role already uses. That renders 512M.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The heaps of the central Elasticsearch, Zammad's Elasticsearch and
Magento's OpenSearch follow their container through the lookup, so far
at half of the limit. That doubled them to 2048, 1024 and 1024 MiB.
Xms equals Xmx, so each container claims that heap from its start, and
the central one locks it in memory.
A quarter of the limit gives 1024, 512 and 512 MiB, the sizes these
engines ran with before. The heap still follows the limit.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A Redis sidecar whose consumer declares no services.redis.mem_limit
runs in a container that inherits the consumer's primary entity limit.
Since the lookup replaced the old filter, maxmemory followed that limit
and rose from 204 MiB to between 819 and 3276 MiB in 17 roles.
lookup('service_memory_mb', ..., provider=<role>) caps the result at
the same share of the provider's own limit when the application does
not declare one for that service. A declared limit is not capped, and a
container smaller than the provider keeps its own share. The Redis
sidecar passes provider='svc-db-redis': those 17 roles get 409 MiB, the
seven with a 256 MiB container stay at 204.
The lookup now rejects unknown options and a provider that is no role
or declares no limit for the service, so a misspelled option fails
instead of silently lifting the cap.
The memcached sidecar's literal -m 64 takes the same lookup and keeps
its value.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
shared_buffers, work_mem and maintenance_work_mem were a quarter, half
and a twentieth of the host's RAM, while the Postgres container is
limited to 6g. On a 64 GB host that asked for 15997 MB of shared
buffers inside it. They are now the same shares of the container's
mem_limit through lookup('service_memory_mb'): 1536 MB, 3072 MB divided
by max_connections, and 307 MB.
The three variables move from group_vars/all/17_resource.yml into the
role's vars. They no longer describe the host, and only the role's
compose template reads them. Their *_MB helpers and POSTGRES_TOTAL_RAM_MB
had no other reader and are gone. An inventory can no longer override
the three values; the knob is services.postgres.mem_limit.
Discourse's db_shared_buffers was a literal 4096MB, all of the 4g the
role declares. It becomes a quarter of that limit, 1024MB. It only
applies when Discourse runs its bundled database.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
