Check update and trigger update

[nsosio]

Check available update

1. Get last premd tag by parsing premd
2. Get sha of the last tag
3. Compare with the sha of available local images

Trigger update

1. Creating a new container of premd (on a different host port)
2. Stop and remove previous container
3. Create a new container with the default host port (on startup event of FastAPI only if the running container is running in a different port than default)

fixes #92

[nsosio]

@casperdcl the solution is super tricky, would it be worth it to have a look at watchtower for automatic update (in this case no endpoint is exposed but watchtower update it.

[casperdcl]

nice; just a few comments

[casperdcl]

deeper review:

1. Creating a new container of premd (on a different host port)
2. Stop and remove previous container
3. Create a new container with the default host port (on startup event of FastAPI only if the running container is running in a different port than default)

Not a fan of any of the above steps (changing ports, changing container names). Instead:

• to avoid port conflict:
  • create (don't run) the new container
  • remove the old container
  • start the new container
• to avoid name suffixes:
  • create a new container with an automatic (random) name
  • remove the old premd container
  • new_container.rename("premd")

Also missing:

• actually pulling the new image
• pruning the old image
• retagging latest

[casperdcl]

aren't we missing here:

• pull get_premd_last_tag()
• update latest tag to point to above
• untag old tag
• after removing old container, prune old image tag

[casperdcl]

should there be an else statement following this if? Don't we need to create a new container if it doesn't already exist?

[casperdcl]

What if this returns False? If you ignore the return value of this function, why call it at all?

[nsosio]

@casperdcl I've reviewed your proposed changes and at first sight I agreed but then I've realised that the problem with

to avoid port conflict:

• create (don't run) the new container
• remove the old container
• start the new container

is that we're starting the new container running the new version of premd from the running premd container itself. Therefore when we stop premd the new container will never be started.

new_container = create_new_container(
    PREMD_IMAGE, "latest", "new_container", "premd"
)
update_and_remove_old_container("premd")
new_container.start() # <-- code never reached
new_container.rename("premd")

That's the main problem of exposing an endpoint to update the container itself.

[casperdcl]

Yep makes sense, so looks like watchtower auto-updates (plus option to disable watchtower) might be a better way to go.

[Janaka-Steph]

Why not calling the API instead?
Something like this, with an authentication token if necessary:

def get_premd_last_tag():
    try:
        url = f'https://api.github.com/orgs/premai-io/packages/container/premd/versions'
        headers = {
            'Accept': 'application/vnd.github+json'
        }
        response = requests.get(url, headers)
        if response.status_code == 200:
            data = response.json()
            if data:
                # Find the latest version by sorting by created_at in descending order
                latest_version = max(data, key=lambda x: x['created_at'])
                return latest_version['name']
            else:
                print("No versions found for the image.")
        else:
            logger.error(f"Failed to retrieve data from GitHub API. Status code: {response.status_code}")
            return None
    except Exception as e:
        logger.error(f"An error occurred: {e}")
        return None

[casperdcl]

because we'd have to hardcode an auth token (this particular API requires authentication even to access public info)

[tiero]

AFAICT is an internal updater functionality for premd itself, not the entire stack of all services (app, dnsd, controllerd, authd etc..)

Main difference with this service is mainly that will be dedicated and can arbitrarily restart any other service without going offline in the first place (ie. the app can monitor the update and don't disrupt serving updates to clients)

That being said not urgent to come to a consensus in this sprint.

[casperdcl]

PoC: bit-gpt/app#458