Summary
If any service has a metadata only update, the supervisor will acquire the lock for all services, even if there are images to download.
This goes against the download-then-kill update strategy as the user's app is no longer able to assume control of the lock since the supervisor obtains it from the start of the download, and doesn't release it until the containers are restarted and the update is applied.
Expected behaviour
Locks should only be acquired after all images are downloaded, reflecting the default download-then-kill update strategy as documented here.
Steps to reproduce
- Deploy a multi-service application where some services require an image download and some services are unchanged (to force a metadata only update)
- Observe the supervisor logs - the
Take update locks indicates the lock hoarding