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

ENH: Print docker image used at beginning of aws-batch jobs #254

Open
corneliusroemer opened this issue Feb 20, 2023 · 2 comments
Open

ENH: Print docker image used at beginning of aws-batch jobs #254

corneliusroemer opened this issue Feb 20, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@corneliusroemer
Copy link
Member

I was trying to see why a bug happened in a recent monkeypox CI run. I couldn't reproduce locally using the latest docker-base image.

I couldn't figure out which docker image was used for the run on aws-batch. Would it be possible to print the docker image tag at the beginning of a run so it can be found in logs?

@corneliusroemer corneliusroemer added the enhancement New feature or request label Feb 20, 2023
@corneliusroemer
Copy link
Member Author

corneliusroemer commented Feb 20, 2023

Actually I found the docker tag in the job description. But maybe there's still a use to have it in the logs.

Also, it might be neat to have versions of the major commands we've installed in the logs as well: things like augur commit, biopython version etc.

Something like pip list could be super helpful when debugging.

@tsibley
Copy link
Member

tsibley commented Mar 1, 2023

FWIW, the default image is shown in the output of nextstrain build --help-all under the --image option's description, e.g.:

  --image <image>       Container image name to use for the Nextstrain runtime
                        (default: nextstrain/base:build-20230228T200714Z for
                        Docker and AWS Batch,
                        docker://nextstrain/base:build-20230119T003940Z for
                        Singularity)

The values shown there will be specific to each setup.

Versions of the major first-party tools in our runtimes are reported by nextstrain version --verbose, e.g.:

nextstrain.cli 6.2.0

Python
  /home/tom/.nextstrain/cli-standalone/nextstrain
  3.10.9 (main, Dec 21 2022, 04:02:04) [Clang 14.0.3 ]

Runners
  docker (default)
    nextstrain/base:build-20230228T200714Z (caefc495d14d, 2023-02-28 13:13:18 -0800 PST)
    augur 21.0.1
    auspice v2.43.0
    fauna a2a1907
    sacra not present

  conda 
    nextstrain-base 20230208T180335Z (hb0f4dca_1_locked, nextstrain)
    augur 21.0.0
    auspice 2.43.0

  singularity 
    docker://nextstrain/base:build-20230119T003940Z (/home/tom/.nextstrain/runtimes/singularity/images/nextstrain/base/build-20230119T003940Z.sif)
    augur 19.3.0
    auspice v2.42.0
    fauna 6d1cede
    sacra not present

  ambient 
    unknown

  aws-batch 
    unknown

For AWS Batch, granted, you have to know that it uses the same Docker image and thus will have the same versions. (The recent bug with amd64 vs. arm64 notwithstanding.)

As for more general, broad debugging information, it maybe seems appropriate for unattended builds (such as those launched with --aws-batch --detach), but pretty log-cluttering for attended builds, esp. non-AWS Batch builds. This seems to me more like debugging information we could choose to emit from the workflow itself (e.g. closest to the place the commands like augur are used), rather than in Nextstrain CLI's runners. Since workflow engines may augment our runtime with their own environments, this would be less potentially misleading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
No open projects
Development

No branches or pull requests

2 participants