Upgrade qless to v0.15.0 for Valkey compatibility

[ladanmoz]

Problem

After upgrading ElastiCache from Redis 5.0.6 to Valkey 8.2 in Feedstore repo (https://github.com/seomoz/feedstore/pull/1253), the qless-ui dashboard was crash-looping with NOSCRIPT No matching script errors. The existing ECR image (latest, from 2020) used an old qless Ruby gem that didn't handle Valkey's flushed Lua script cache.

Solution

• Updated Gemfile to pin qless to v0.15.0 (adds Valkey 8 support) in qless-docker repo
• Updated Dockerfile base image from ruby:2.4.2-slim-stretch to ruby:3.1-slim-bookworm (Stretch is EOL, builds were failing)
• Removed stale Gemfile.lock (was pinned to qless 0.11.0)

How this was tested

Pushed 1.3.0 and latest tags to ECR (594715671849.dkr.ecr.us-east-1.amazonaws.com/qless-ui)
Force-restarted ECS service in Feedstore repo:

aws ecs update-service --cluster feedstore-write \
  --service data-platform-dev-feedstore-write-qless \
  --force-new-deployment

Verification:

[x] Qless UI loads at feedstore-write-qless.data-platform-dev.aws.moz.com/qless
[x] No NOSCRIPT errors
[x] Workers connected and processing jobs

[whoislockemui]

rather than being deleted, should this be updated with the new required versions?

[ladanmoz]

I deleted the Gemfile.lock because it was pinned to the old qless 0.11.0 and wouldn't work with v0.15.0. A fresh lock file gets generated automatically when Docker runs bundle install during the build.

[whoislockemui]

ok, so shouldn't that fresh lock file get checked in?

[ladanmoz]

good point, I'll extract the lock file from the build and commit it to the PR

[CorbinGraham]

Double checking on this. You're saying that this Lock file is pulled from the built Docker image itself correct?

[whoislockemui]

looks ok to me, but please get one more dev to approve

[CorbinGraham]

Root Ruby version for Qless is 2.4.2. This only installs 3.1. Does Qless just not care what version was installed when starting up the container?

[koos42]

It is likely impossible to find a ruby container in 2.4.2 for a base image, short of making one from scratch. It's possible that it doesn't have any breaking changes that need addressing in 3.1?

[koos42]

Does it do all the things, when you've pushed it to ECS? Pause/unpause queues, retry jobs, cancel jobs, etc.?