Re: [meta-virtualization][PATCH 4/7] recipes-containers/images: add app-container-valkey

On 2026-06-12 11:11:24-07:00, Bruce Ashfield wrote:
> Hi Tim,
> 
> Two valkey-specific comments — the series-level points from 2/7 and 3/7
> apply here too but I won't re-raise them.
> 
> On Fri, May 29, 2026 at 18:31 -0700, Tim Orling wrote:
> 
> > Add OCI container image recipe for the Valkey in-memory key-value
> > datastore. The image uses multi-layer mode with separate base and
> > valkey layers, exposes the standard Valkey port (6379), and launches
> > valkey-server with its default config file as the entrypoint.
> 
> [...]
> 
> > +OCI_IMAGE_ENTRYPOINT = "${bindir}/valkey-server"
> > +# The stock valkey.conf shipped by meta-oe is tuned for a host install
> > +# (daemonize yes, syslog-enabled yes, bind 127.0.0.1). Override those at
> > +# launch so the server stays in the foreground as PID 1, logs to stdout,
> > +# and is reachable from outside the container.
> > +OCI_IMAGE_ENTRYPOINT_ARGS = "'${sysconfdir}/valkey/valkey.conf' \
> > +    --daemonize no \
> > +    --syslog-enabled no \
> > +    --bind '0.0.0.0 -::*' \
> > +    --protected-mode no"
> 
> The override-the-conf-at-launch trick is nice, I like it, and it's
> documented in the comments.
> 
> What about a description of `--protected-mode no` ?

Although I also like the override-the-conf-at-launch, on further review of
upstream containers, they use tini and an entrypoint.sh script to launch
with a .conf if passed in on the command line and otherwise no conf.

The whole reason I did the override-the-conf-at-launch was that the default
valkey.conf provided by our valkey recipe was not launching cleanly.

I'm a little concerned that by doing the overrides with OCI_IMAGE_ENTRYPOINT_ARGS
like this it will be more confusing for the end user to re-use the container.

> 
> I quickly searched and found with protected-mode off and bind on all
> interfaces, anyone who can reach the container gets unauthenticated
> access — that's the right default for a base image people will pull
> and customise, but a deployer who slaps this into production without
> adding AUTH or namespace isolation gets a surprise. Worth a single
> sentence in DESCRIPTION saying so explicitly:
> 
> Maybe this ?
> 
>   DESCRIPTION = "OCI container running the Valkey in-memory key-value \
>   datastore, a flexible distributed datastore that supports both caching \
>   and beyond caching workloads. This image runs with protected-mode \
>   disabled and bound to all interfaces, intended as a base for \
>   customisation — production deployments should enable requirepass / \
>   ACLs or restrict the network namespace."
> 
> The second is the same persistence question I asked on mosquitto. The
> stock meta-oe valkey.conf may or may not enable AOF / RDB snapshotting
> (`appendonly yes` / `save <seconds> <writes>`). If either is on,
> valkey-server tries to write to its `dir` (usually /var/lib/valkey).
> Running as our nonroot uid 65532 against a /var/lib/valkey owned by the
> valkey package user will fail-to-write or worse, silently lose data.
> 
> Did you confirm during testing whether the stock conf has persistence
> on? If on, we want a /var/lib/valkey fixup similar to the
> /var/volatile one. If off, a one-line comment saying so would save the
> next person from re-deriving it.
> 
> Bruce