Issues with proteomics container

[lgatto]

Things are getting a bit weird with the proteomics container. I am documenting my progress (or lack thereof here), and may be someone can chime in.

Currently, both release and devel fail. But I get release to build locally:

But devel fails

I believe that these fail should be fixed with the addition of libxt-dev in mscore, but...

On release, it is present, which is consistent with the positive result above

On devel, it is *not present, which is consistent with the negative result above

Not sure why ...

[lgatto]

@lshep - could trigger a new push when you have a minute. Thanks!

[lshep]

@lgatto for the dockerhub repositories? I can but I thought you figured out how to trigger builds this weekend?

[lshep]

I just triggered the release_mscore2 and will follow with the release_proteomics2 ... if successful I will move onto devel.

[lgatto]

I thought so, but the Dockerfile doesn't reflect my latest push

It should be

# The suggested name for this image is: bioconductor/devel_mscore.

FROM bioconductor/devel_base2

MAINTAINER lg390@cam.ac.uk

RUN apt-get update -qq && \
    apt-get install -y  --no-install-recommends \
    libxt-dev libx11-dev libcairo2-dev \
    libfreetype6 \    
    libexpat1-dev \
    libgmp3-dev \
    liblapack-dev \
    libopenbabel-dev \
    libgl1-mesa-dev \

I must be missing a step to actually make sure that the latest content of the out directories are used to build the container.

[lshep]

It should do that automatically. The dockerhub just pulls from the github directory. Maybe it was just too close to the commit. Anyways... it does look like the corrected one is being/has built for mscore2

[lgatto]

I don't think the correct one was build for mscore2, because devel misses libxt-dev, although it is present in the Docker file. mscore2 builds successfully, even when it missed that dependency.

[lshep]

I've only rebuilt the release_mscore2 I haven't build the devel yet.

[lgatto]

Yes, the Docker files for release reflects the latest changes.

[lgatto]

@lshep - what have you done when you say I've only rebuilt the release_mscore2? I think that's the missing step for me.

[lshep]

I've manually triggered the build on the release_mscore2 at https://hub.docker.com/r/bioconductor/release_mscore2/~/settings/automated-builds/ The release_proteomics2 is queued up to build once the latest tag gets built for the release_mscore2 docker also by a manually trigger at https://hub.docker.com/r/bioconductor/release_proteomics2/~/settings/automated-builds/ .

Once the release_proteomics builds successfully I would kick off the devel_mscore2. I wait to do this because the devel builds are all triggered by rebuilds of parent packages. now that the prometcore builds of mscore, prometcore and proteomics would try to build and if prometcore builds successfully then the metabolics will get build so several containers will be queued with the devel_mscore2 . if it needs more changes I would prefer not to have to cancel out all the queued builds (since they get built automatically) Only one build can happen at a time on the dockerhub, they do not happen simultaneously.

[lgatto]

When you say manually triggered do you mean

The trigger buttons at the top

Or the Build triggers at the bottom

[lshep]

At the top.

[lgatto]

There's still something wrong with mscore2. I first pull the latest containers

lg390@elyacin [04:28:07] [~/dev/00_github/bioc_docker] [master]
-> % docker pull bioconductor/devel_mscore2
Using default tag: latest
latest: Pulling from bioconductor/devel_mscore2
Digest: sha256:31bbdc9f2522a675d5faa7a8d52263c4d24b7eb76402b33632e76c3bfc75ba42
Status: Image is up to date for bioconductor/devel_mscore2:latest
lg390@elyacin [04:28:38] [~/dev/00_github/bioc_docker] [master]
-> % docker pull bioconductor/release_mscore2
Using default tag: latest
latest: Pulling from bioconductor/release_mscore2
Digest: sha256:0a6392a4a48e42117bbb9dbe838629c5ede6c5262f5e5471f0b07a295d1b0428
Status: Image is up to date for bioconductor/release_mscore2:latest

Is my dependency available in release_mscore2: YES

-> % docker run -ti bioconductor/release_mscore2 bash
root@fe425d4f255b:/# dpkg --get-selections | grep libxt
libxt-dev:amd64                 install
libxt6:amd64                    install
libxtst6:amd64                  install

Is my dependency available in devel_mscore: NO

-> % docker run -ti bioconductor/devel_mscore2 bash
root@1263132bf283:/# dpkg --get-selections | grep libxt
libxt6:amd64                    install
libxtst6:amd64                  install

This is consistent with the docker files on the docker hub: the latest changes are reflected in release_mscore2, but not devel_mscore2, although there are correct in the out directories on github.

[lshep]

I only tried to build the release versions of the dockers NOT the devel versions. There is still a problem with the release version of release_proteomics2 using the correct version of release_mscore2. I didn't do devel for the reasons stated about with linked dependencies.

[lgatto]

I only tried to build the release versions of the dockers NOT the devel versions.

Ok. it's still confusing that the docker file hasn't been updated.

I will focus on the release for debugging, then.

[lshep]

It has been updated for the release version because the release version got pulled from github when it builds it on dockerhub. If you trigger a build on devel_mscore2 the dockerfile would be updated there; I haven't done this because of the linked containers. The dockerfile has been updated for the release_mscore2.

[lshep]

The dockerfile only gets updated when it pulls from github. It only pulls from github when a build is triggered.

[lgatto]

Thanks, it makes sense now.

[lgatto]

Coming back to what is driving me a bit insane these last day. Locally, I can fire up release_mscore2 and successfully run all the code in out/release_proteomics/install.R.

I can also successfully build release_proteomics2:

lg390@molerat:~/tmp/bioc_docker/out/release_proteomics$ docker build -t local/release_proteomics2 .
[ lots of output here]
The downloaded source packages are in
        ‘/tmp/RtmpxHGrEg/downloaded_packages’
>
> # just in case there were warnings, we want to see them
> # without having to scroll up:
> warnings()
NULL
>
> if (!is.null(warnings())) {
+     w <- capture.output(warnings())
+     if (length(grep("is not available|had non-zero exit status", w)))
+         quit("no", 1L)
+ }
>
> suppressWarnings(BiocInstaller::biocValid(fix=TRUE, ask=FALSE))
[1] TRUE
>
 ---> 8677822df88c
Removing intermediate container ad0e4b7d3ce0
Successfully built 8677822df88c

and

lg390@molerat:~/tmp/bioc_docker/out/release_proteomics$ docker images
REPOSITORY                     TAG                 IMAGE ID            CREATED              VIRTUAL SIZE
local/release_proteomics2      latest              8677822df88c        20 minutes ago       6.164 GB
bioconductor/release_mscore2   latest              4b48396ff366        6 hours ago          1.73 GB
bioconductor/devel_mscore2     latest              b77b86625ba2        7 days ago           3.715 GB
haskell                        latest              754074761f63        2 weeks ago          961.1 MB
ubuntu                         latest              f5bb94a8fac4        2 weeks ago          117.3 MB
ubuntu                         14.04               9df772af0cb9        4 weeks ago          188 MB
hdd                            latest              1392acd6f829        2.280377 years ago   1.675 GB
haskell                        7.8                 7093a9a3a5cc        2.371320 years ago   601.3 MB

What am I missing? Why does it fail remotely?

[lgatto]

The remote build failed again, with the same message - it just says

Build canceled.

The container builds fine locally - is there a time out on docker hub?

I am running out of ideas; I am going to try with a different parent container.

[lgatto]

@lshep @sneumann - any idea what this Build canceled means?

[lgatto]

I couldn't find much, just

If the Docker client loses connection to the daemon, the build is canceled. This happens if you interrupt the Docker client with CTRL-c or if the Docker client is killed for any reason. If the build initiated a pull which is still running at the time the build is cancelled, the pull is cancelled as well.

[lshep]

Something to also keep in mind, I want to say if there are issues with any package installations in R it will also cause the Docker to fail to build on dockerhub.

[lgatto]

Yes, and that should be reflected with a message like

1: In install.packages(pkgs = doing, lib = lib, ...) : installation of package ‘ChemmineR’ had non-zero exit status 
2: In install.packages(pkgs = doing, lib = lib, ...) : installation of package ‘bioassayR’ had non-zero exit status

Or do you mean something else?

[sneumann]

What is the difference between the R3.4.0_Bioc3.5 and latest builds ? Recently it seems one of them failled, the other cancelled. Are these two separate builds, or one build and (if that were successful) one more tagged, which is cancelled if the first one failed ? Just guessing here.

[sneumann]

What is the difference between the R3.4.0_Bioc3.5 and latest builds ? Recently it seems one of them failled, the other cancelled. Are these two separate builds, or one build and (if that were successful) one more tagged, which is cancelled if the first one failed ? Just guessing here.

[lshep]

When you manually trigger the R3.4.0_Bioc3.5 it automatically adds a second build for latest. It runs the code again to get each Tag option for the container. Since the dockerhub runs only one build at a time not simultaneously, if I notice/am watching the builds and the R3.4.0_Bioc3.5 fails to build, I cancel out the second build of latest manually since it will also fail.

[lgatto]

Following up on the issues with the proteomics container, @sneumann successfully built it locally (thank you for testing, Steffen). As the build does take some time (2+ hours), it is likely that the build canceled is the result of a time out, which is consistent with this post. (although a bit out dated).

I am going to use protmetcore as parent for proteomics, as that container has already some packages pre-installed. This failed last time I tried because protmetcore hadn't been re-build using mscore, which has the some required dependencies for to successfully install Cairo.

Unless anyone object, I am going to do the following to make sure all parents are up-to-date.

0. Update the config with new parent
1. trigger a release_protmetcore2 build
2. once 1 is successful, trigger a release_proteomics2 build

[lgatto]

Bonus question:

Does anyone know how, or if at all possible to increase the timeout?

[sneumann]

I could imagine that docker Inc. Has a plan that involves a monthly sum of money...

---

I blame Android for the brevity and typos

[lgatto]

The images build successfully when I reduce the number of packages to be installed, suggesting that a timeout is indeed the problem.

[lgatto]

This has been solved by creating a protcore container.