Skip to content

Supervisor doesn't honour download-then-kill update strategy for metadata only updates #2440

@robthein

Description

@robthein

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

  1. Deploy a multi-service application where some services require an image download and some services are unchanged (to force a metadata only update)
  2. Observe the supervisor logs - the Take update locks indicates the lock hoarding

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions