Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Latest docker image is broken #1770

Closed
Wolfy18 opened this issue May 22, 2024 · 13 comments
Closed

[BUG] Latest docker image is broken #1770

Wolfy18 opened this issue May 22, 2024 · 13 comments
Assignees

Comments

@Wolfy18
Copy link

Wolfy18 commented May 22, 2024

Describe the bug
After restarting the container, the guild deploy.sh script ran and updated the Koios scripts which is incompatible with the version 8.7.3

NETWORK: preprod
NODE: 86c1480c82ae - Port:6000 -
cardano-node 8.7.3 - linux-x86_64 - ghc-8.10
git rev a4a8119b59b1fbb9a69c79e1e6900e91292161e7
Restore Started
Restore Finished

Koios scripts have now been upgraded to support cardano-node 8.9.x ('8.7.3' found) / cardano-cli 8.20.x.x ('8.17.0.0' found).
Please update cardano-node binaries (ensure to read release notes and update various configs using guild-deploy (use appropriate options to download/install/overwrite parts you need) or use tagged branches for older node version (eg: ./<script>.sh -b node-8.1.2 to switch scripts to an older branch).

To Reproduce
Steps to reproduce the behavior:

  1. Create service using the cardano node image located https://hub.docker.com/r/cardanocommunity/cardano-node/tags
  2. Start docker compose
  3. See error

Expected behavior
The node should start automatically

Version:

  • OS: Linux Ubuntu 22
  • Product version: Docker Image 3233b0c4a8f7
  • Cardano Node version: 8.7.3
  • Network you're connecting to: Preprod and Mainnet

Additional context
The docker image should be updated to use the latest node version 8.9.2

@Wolfy18 Wolfy18 changed the title Latest docker image is broken [BUG] Latest docker image is broken May 22, 2024
@TrevorBenson
Copy link
Collaborator

TrevorBenson commented May 22, 2024

I've just kicked off a new build from the master branch. After alpha recent merge into master this should result in bundling 8.9.2 into the container. I will report back later today once I confirm the 8.9.2 node binaries are inside the updated image.

I have a separate branch that should automatically kick off builds when alpha merges into master. I'll get that PR opened soon to reduce the time delay between the merge and a new container being made available.

@Wolfy18
Copy link
Author

Wolfy18 commented May 22, 2024

@TrevorBenson Is there a way to avoid this to happen in the future? I know there's a way to set the branch for the deploy script. guild-deploy.sh -b node-8.7.3. Maybe we could update the entrypoint.sh of the docker image to use the current version of its image, otherwise it won't be fallback compatible.

@TrevorBenson
Copy link
Collaborator

@Wolfy18 The current container on hub.docker.com should be available with 8.9.2 bundled in:

$ podman run --rm -it --entrypoint cardano-node cardanocommunity/cardano-node:latest --version
cardano-node 8.9.2 - linux-x86_64 - ghc-8.10
git rev 424983fa186786397f5a99539f51710abf62c37b

@TrevorBenson
Copy link
Collaborator

TrevorBenson commented May 22, 2024

@TrevorBenson Is there a way to avoid this to happen in the future?

I'll investigate a little and see if something comes to mind. I've used the koios API, but haven't put up my own instances of koios endpoints, so @rdlrt or @Scitz0 are likely to have useful feedback in this regards.

I know there's a way to set the branch for the deploy script. guild-deploy.sh -b node-8.7.3. Maybe we could update the entrypoint.sh of the docker image to use the current version of its image, otherwise it won't be fallback compatible.

Not sure I understand the context of current version of its image in regards to changing entrypoint.sh. Can you elaborate on this suggestion?

@TrevorBenson TrevorBenson self-assigned this May 22, 2024
@rdlrt
Copy link
Contributor

rdlrt commented May 22, 2024

Is there a way to avoid this to happen in the future?

There is already environment variable UPDATE_CHECK , guild-deploy is run in entrypoint when it's value is 'Y'
So rather than hardcoding version (which requires update for every release and is stuck to commit), the outcome is better achieved using this variable [which is the same if not using docker too]

@rdlrt rdlrt closed this as completed May 22, 2024
@Wolfy18
Copy link
Author

Wolfy18 commented May 22, 2024

Not sure I understand the context of current version of its image in regards to changing entrypoint.sh. Can you elaborate on this suggestion?

The entrypoint of the docker image is calling the /home/guild/entrypoint.sh file which runs the guild-deploy.sh script. We can get the node version in the same script @rdlrt

NODE_VERSION="node-$(cardano-node --version | grep cardano-node | awk '{print $2}')" # node-8.7.3

guild-deploy.sh -b $NODE_VERSION -n mainnet

@Wolfy18
Copy link
Author

Wolfy18 commented May 22, 2024

Is there a way to avoid this to happen in the future?

There is already environment variable UPDATE_CHECK , guild-deploy is run in entrypoint when it's value is 'Y' So rather than hardcoding version (which requires update for every release and is stuck to commit), the outcome is better achieved using this variable [which is the same if not using docker too]

For the record. I did use UPDATE_CHECK=N, and it did not work for me

@rdlrt
Copy link
Contributor

rdlrt commented May 22, 2024

Not sure I understand the context of current version of its image in regards to changing entrypoint.sh. Can you elaborate on this suggestion?

The entrypoint of the docker image is calling the /home/guild/entrypoint.sh file which runs the guild-deploy.sh script. We can get the node version in the same script @rdlrt

NODE_VERSION="node-$(cardano-node --version | grep cardano-node | awk '{print $2}')" # node-8.7.3

guild-deploy.sh -b $NODE_VERSION -n mainnet

Makes no sense tbh, if you dont want to upgrade the scripts, why run guild-deploy on every restart at all?

For the record. I did use UPDATE_CHECK=N, and it did not work for me

The support for that environment variable to control updates was only added recently via #1754

@Wolfy18
Copy link
Author

Wolfy18 commented May 22, 2024

Makes no sense tbh, if you dont want to upgrade the scripts, why run guild-deploy on every restart at all?

Have you look at the file entrypoint.sh? that runs every time the container starts

https://hub.docker.com/layers/cardanocommunity/cardano-node/8.7.3/images/sha256-3233b0c4a8f761a93abd8f194e670f6428ca41065b4adfc773b14ab509c75581

export UPDATE_CHECK='N'

if [[ "$NETWORK" == "mainnet" ]]; then
  $CNODE_HOME/scripts/guild-deploy.sh -n mainnet -u -s f > /dev/null 2>&1 \
  && customise \
  && exec $CNODE_HOME/scripts/cnode.sh
elif [[ "$NETWORK" == "preprod" ]]; then
  $CNODE_HOME/scripts/guild-deploy.sh -n preprod -u -s f > /dev/null 2>&1 \
  && customise \
  && exec $CNODE_HOME/scripts/cnode.sh
elif [[ "$NETWORK" == "preview" ]]; then

@rdlrt
Copy link
Contributor

rdlrt commented May 22, 2024

@Wolfy18 Please read the complete msg and linked PR 🙂

@Wolfy18
Copy link
Author

Wolfy18 commented May 23, 2024

@Wolfy18 Please read the complete msg and linked PR 🙂

Maybe I didn't explain myself properly. Have you tried running an instance 8.7.3 of the docker image? The entrypoint.sh file runs every time the container starts. It will automatically update Koios scripts to the master branch (This is the default behavior) although the binaries are still version 8.7.3.

This is the error showing up

Koios scripts have now been upgraded to support cardano-node 8.9.x ('8.7.3' found) / cardano-cli 8.20.x.x ('8.17.0.0' found).
Please update cardano-node binaries (ensure to read release notes and update various configs using guild-deploy (use appropriate options to download/install/overwrite parts you need) or use tagged branches for older node version (eg: ./<script>.sh -b node-8.1.2 to switch scripts to an older branch).

This has nothing to do with the PR you mentioned. That PR is related to gLiveView.sh

@TrevorBenson
Copy link
Collaborator

TrevorBenson commented May 23, 2024

@Wolfy18 Take a closer look at the files in the PR, as the PR description mentions it also closes #1750 and the guild-deploy.sh usage is limited to when UPDATE_CHECK=Y which is now embedded into the ENV via the Dockerfile that builds the container. The configs & scripts are now "baked in" to the container and will not update on each restart. The operator has to intentionally pass along UPDATE_CHECK=Y to get the original behavior and update the configs and/or scripts from the upstream master branch.

This should prevent the behavior you describe. Give it a try on the new container built yesterday to confirm.

@rdlrt
Copy link
Contributor

rdlrt commented May 23, 2024

@Wolfy18 we do fully understand (from first post) what you're receiving and saying - what is being said is the issue is no longer applicable on current builds and has better solution than suggestion in this thread (8.7.3 is old tag and we wont be going back to change commits/node support for old tags) , so if you go for upgrade - it should no longer occur against future node version updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants