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

finishing up v2.4 docker to singularity conversion #27

Closed
wants to merge 5 commits into from
Closed

Conversation

vsoch
Copy link
Member

@vsoch vsoch commented Oct 19, 2017

hey @singularityware/singularity-admin @chrisfilo here is a first shot at docker2singularity conversion for 2.4. We do the following:

  1. use an empty build sandbox to construct the image from docker export
  2. use the folder to build a squashfs image

I had some trouble with the check for busybox to determine if -executable should be used or not. For an ubuntu test image, it triggered the case that failed. If it's the case that not using executable works for both busybox and other flavors, I just removed that step. But I'm not familiar with the addition.

Chris - squashfs can be converted back to a writable thing, if needed. I will leave it up for open discussion to decide how we should maintain the branches (e.g., there are many benefits to squashfs that would make it an appealing default). Take a look at the changes and let me know your thoughts! I'm likely closing up shop soon, I think it's 10pm here, and I haven't gone home yet... oups :P

@chrisgorgo
Copy link
Collaborator

chrisgorgo commented Oct 21, 2017 via email

@vsoch
Copy link
Member Author

vsoch commented Oct 21, 2017

No worries! Please take the time that you need. Happy Friday! 🍨

@vsoch vsoch mentioned this pull request Oct 26, 2017
@chrisgorgo
Copy link
Collaborator

I tested it on the following images:

  • poldracklab/mriqc
  • ubuntu
  • continuumio/miniconda
  • bids/cpac

Conversion did not error for any of them, but the bids/cpac image does not work correctly after conversion using this branch:

PS D:\drive\workspace\docker2singularity> docker run -ti --rm --read-only bids/cpac
usage: run.py [-h] [--pipeline_file PIPELINE_FILE]
              [--data_config_file DATA_CONFIG_FILE]
              [--aws_input_creds AWS_INPUT_CREDS]
              [--aws_output_creds AWS_OUTPUT_CREDS] [--n_cpus N_CPUS]
              [--mem_mb MEM_MB] [--mem_gb MEM_GB] [--save_working_dir]
              [--participant_label PARTICIPANT_LABEL [PARTICIPANT_LABEL ...]]
              [--participant_ndx PARTICIPANT_NDX] [-v]
              bids_dir output_dir {participant,group,test_config,GUI}
run.py: error: too few arguments

With old converter (using .img)

[chrisgor@sh-ln02 login! ~]$ singularity run -c -e /share/PI/russpold/singularity_images/bids_cpac-2017-03-29-b91418919662.img
usage: run.py [-h] [--pipeline_file PIPELINE_FILE]
              [--data_config_file DATA_CONFIG_FILE]
              [--aws_input_creds AWS_INPUT_CREDS]
              [--aws_output_creds AWS_OUTPUT_CREDS] [--n_cpus N_CPUS]
              [--mem_mb MEM_MB] [--mem_gb MEM_GB] [--save_working_dir]
              [--participant_label PARTICIPANT_LABEL [PARTICIPANT_LABEL ...]]
              [--participant_ndx PARTICIPANT_NDX] [-v]
              bids_dir output_dir {participant,group,test_config,GUI}
run.py: error: too few arguments

with new converter

[chrisgor@sh-ln02 login! ~]$ singularity run -c -e /share/PI/russpold/singularity_images/bids_cpac-2017-03-29-c780e38ca1e9.simg
Traceback (most recent call last):
  File "/code/run.py", line 5, in <module>
    import yaml
ImportError: No module named yaml

@vsoch
Copy link
Member Author

vsoch commented Oct 27, 2017

Great news! I'll test out that last one this weekend. Thanks for testing these out, I'll keep you updated if I figure out the last one.

@chrisgorgo
Copy link
Collaborator

chrisgorgo commented Oct 27, 2017 via email

@vsoch
Copy link
Member Author

vsoch commented Oct 27, 2017

Good idea. I'll have the default build a folder (sandbox) to simg, and then the user can choose to either keep the folder (for development) OR to produce instead an ext3 image. I will think more about the specific commands and include them in my notes after testing.

@vsoch
Copy link
Member Author

vsoch commented Oct 28, 2017

hey @chrisfilo ! A quick answer for you. The reason for the missed import is that yaml is installed under miniconda at /usr/local/bin/miniconda and the runscript specifies to use python from the environment (#!/usr/bin/env python) and the active python (after building the buggy container) is:

$ which python
/usr/bin/python

and we can see yaml is where it should be, with miniconda

$ /usr/local/bin/miniconda/bin/python
Python 2.7.13 |Continuum Analytics, Inc.| (default, Dec 20 2016, 23:09:15) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import yaml

and this all stems from the fact that for the new build command, when we build from a sandbox folder it doesn't include the typical metadata bits (bootstrap did). I should be able to fix this up.

@vsoch
Copy link
Member Author

vsoch commented Oct 28, 2017

Okay, you can check out the updated README to see the usage, and I'll show examples here! First, some general comments:

  • we don't need to worry about figuring out a pre-specified size, ever again
  • the default format is much smaller than previous
  • users have options to choose any format, and all formats can be converted to others later if needed

The user has the option to build:

  • squashfs (no arguments specified) gives you a squashfs (*.simg) image. This is a compressed, reliable, and read only format that is recommended for production images.
  • sandbox (-f) builds your image into a sandbox folder. This is ideal for development, as it will produce a working image in a folder on your system.
  • ext3 (-w) builds an older format (ext3) image (*.img). This format is not recommended for production images as we have observed degradation of the images over time, and they tend to be upwards of 1.5x to 2x the size of squashfs.

Build into Sandbox Folder

I'll start with a folder, because we can easily peek inside to see some changes. By specifying -f the user can build a sandbox folder (very useful for development)

docker run -v /var/run/docker.sock:/var/run/docker.sock -v /home/vanessa/Desktop:/output --privileged -t --rm docker2singularity -f bids/cpac

Image Format: sandbox
Inspected Size: 3689 MB
(1/9) Creating a build sandbox...
(2/9) Exporting filesystem...
(3/9) Adding run script...
(4/9) Setting ENV variables...
(5/9) Adding mount points...
(6/9) Fixing permissions...
(7/9) Stopping and removing the container...
(8/9) Building sandbox container...
(9/9) Moving the image to the output folder...
  4,830,419,466  99%  200.87MB/s    0:00:22 (xfr#103037, to-chk=0/121041)   
Final Size: 3606MB

let's go look at it...

cd -
/home/vanessa/Desktop
$ singularity run bids_cpac-2017-03-29-c8816111946c/
usage: run.py [-h] [--pipeline_file PIPELINE_FILE]
              [--data_config_file DATA_CONFIG_FILE]
              [--aws_input_creds AWS_INPUT_CREDS]
              [--aws_output_creds AWS_OUTPUT_CREDS] [--n_cpus N_CPUS]
              [--mem_mb MEM_MB] [--mem_gb MEM_GB] [--save_working_dir]
              [--participant_label PARTICIPANT_LABEL [PARTICIPANT_LABEL ...]]
              [--participant_ndx PARTICIPANT_NDX] [-v]
              bids_dir output_dir {participant,group,test_config,GUI}
run.py: error: too few arguments

Note that it runs without error. Also note that it's a folder, and we can see that this updated docker2singularity has a proper metadata folder (.singularity.d)

tree -L 1 bids_cpac-2017-03-29-c8816111946c/
bids_cpac-2017-03-29-c8816111946c/
├── bin
├── boot
├── code
├── cpac_resources
├── dev
├── environment -> .singularity.d/env/90-environment.sh
├── etc
├── home
├── lib
├── lib64
├── local-scratch
├── media
├── mnt
├── oasis 
├── opt
├── proc
├── root
├── run
├── sbin
├── scratch
├── singularity -> .singularity.d/runscript
├── singularity.json
├── srv
├── sys
├── tmp
├── usr
└── var

instead of having /environment we mirror the practice of docker import and add it to 10-docker.sh

tree -L 1 bids_cpac-2017-03-29-c8816111946c/.singularity.d/env/
bids_cpac-2017-03-29-c8816111946c/.singularity.d/env/
├── 01-base.sh
├── 10-docker.sh
├── 90-environment.sh
├── 95-apps.sh
└── 99-base.sh

and the runscript

cat bids_cpac-2017-03-29-c8816111946c/.singularity.d/runscript 
#!/bin/sh
/code/run.py $@

Build Squashfs

Now let's look at the default, which is to build a squashfs image:

docker run -v /var/run/docker.sock:/var/run/docker.sock -v /home/vanessa/Desktop:/output --privileged -t --rm docker2singularity bids/cpac

Image Format: squashfs
Inspected Size: 3689 MB

(1/9) Creating a build sandbox...
(2/9) Exporting filesystem...
(3/9) Adding run script...
(4/9) Setting ENV variables...
(5/9) Adding mount points...
(6/9) Fixing permissions...
(7/9) Stopping and removing the container...
(8/9) Building squashfs container...
Building image from sandbox: /tmp/bids_cpac-2017-03-29-274df13a156c.build
Building Singularity image...
Singularity container built: /tmp/bids_cpac-2017-03-29-274df13a156c.simg
Cleaning up...
(9/9) Moving the image to the output folder...
  1,402,847,263 100%  275.90MB/s    0:00:04 (xfr#1, to-chk=0/1)
Final Size: 1338MB

Look at the difference in size!! 3689MB down to 1338MB and more robust! Woot! Let's test it out...

singularity run bids_cpac-2017-03-29-274df13a156c.simg 
usage: run.py [-h] [--pipeline_file PIPELINE_FILE]
              [--data_config_file DATA_CONFIG_FILE]
              [--aws_input_creds AWS_INPUT_CREDS]
              [--aws_output_creds AWS_OUTPUT_CREDS] [--n_cpus N_CPUS]
              [--mem_mb MEM_MB] [--mem_gb MEM_GB] [--save_working_dir]
              [--participant_label PARTICIPANT_LABEL [PARTICIPANT_LABEL ...]]
              [--participant_ndx PARTICIPANT_NDX] [-v]
              bids_dir output_dir {participant,group,test_config,GUI}
run.py: error: too few arguments

Legacy Format

If the user wants the legacy format, that is available with -w:

docker run -v /var/run/docker.sock:/var/run/docker.sock -v /home/vanessa/Desktop:/output --privileged -t --rm docker2singularity -w bids/cpac

Image Format: writable
Inspected Size: 3689 MB

(1/9) Creating a build sandbox...
(2/9) Exporting filesystem...
(3/9) Adding run script...
(4/9) Setting ENV variables...
(5/9) Adding mount points...
(6/9) Fixing permissions...
(7/9) Stopping and removing the container...
(8/9) Building writable container...
Building image from sandbox: /tmp/bids_cpac-2017-03-29-189989307b50.build
Creating empty Singularity writable container 3606MB
Creating empty 4507MiB image file: /tmp/bids_cpac-2017-03-29-189989307b50.img
4507+0 records in
4507+0 records out
Formatting image with ext3 file system
Image is done: /tmp/bids_cpac-2017-03-29-189989307b50.img
Building Singularity image...
Singularity container built: /tmp/bids_cpac-2017-03-29-189989307b50.img
Cleaning up...
(9/9) Moving the image to the output folder...
  4,725,932,063 100%  259.65MB/s    0:00:17 (xfr#1, to-chk=0/1)
Final Size: 4508MB

and test...

singularity run bids_cpac-2017-03-29-189989307b50.img 
usage: run.py [-h] [--pipeline_file PIPELINE_FILE]
              [--data_config_file DATA_CONFIG_FILE]
              [--aws_input_creds AWS_INPUT_CREDS]
              [--aws_output_creds AWS_OUTPUT_CREDS] [--n_cpus N_CPUS]
              [--mem_mb MEM_MB] [--mem_gb MEM_GB] [--save_working_dir]
              [--participant_label PARTICIPANT_LABEL [PARTICIPANT_LABEL ...]]
              [--participant_ndx PARTICIPANT_NDX] [-v]
              bids_dir output_dir {participant,group,test_config,GUI}
run.py: error: too few arguments

This image format is less ideal because it's larger, more prone to corruption over time, and likely to not have future support.

Conversion

Importantly, any format can be converted to another format easily, for example, let's convert the ext3 image to squashfs:

sudo singularity build production.simg bids_cpac-2017-03-29-189989307b50.img 
Building from local image: bids_cpac-2017-03-29-189989307b50.img
Building Singularity image...
Singularity container built: production.simg
Cleaning up...

$ du -shm production.simg 
1338	production.simg

and that would work for the sandbox folder too. Still not recommended, because if there were changes not recorded, this is not reproducible.

@vsoch
Copy link
Member Author

vsoch commented Oct 28, 2017

huh, I wonder if I can get the labels from the image too? Let me try that.

README.md Outdated
ubuntu:14.04
```

Replace `D:\host\path\where\to\output\singularity\image` with a path on the host filesystem where your Singularity image will be created. Replace `ubuntu:14.04` with the docker image name you wish to convert (it will be pulled from Docker Hub if it does not exist on your host system).

`docker2singularity` uses the Docker daemon located on the host system. It will access the Docker image cache from the host system avoiding having to redownload images that are already present locally.

## Build a Squashfs Image
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you mention here what is the minimal version of Singularity required to run Squashfs images?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can find when support was added in the source code, but I don't recall if there were any issues. If they were they would have been fixed later. I will cite when support was added and if users have issues I will help them.

README.md Outdated
@@ -16,14 +58,66 @@ docker run \
-v /var/run/docker.sock:/var/run/docker.sock \
-v D:\host\path\where\to\output\singularity\image:/output \
--privileged -t --rm \
singularityware/docker2singularity \
singularityware/docker2singularity:2.4 \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used tags so far to denote the version of docker client inside the container (see below - the client version needed to be compatible with the host version). I don't think we need to add tags here for singularity version. After this is merged I will make sure all branches will get updated.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok I'll remove that

@vsoch
Copy link
Member Author

vsoch commented Oct 28, 2017

To keep a record in our discussion, here is how the modified generation looks, showing an added step to generate metadata labels

docker run -v /var/run/docker.sock:/var/run/docker.sock \
-v /host/path/change/me:/output \
--privileged -t --rm \
singularityware/docker2singularity
ubuntu:14.04

Image Format: squashfs
Inspected Size: 188 MB

(1/10) Creating a build sandbox...
(2/10) Exporting filesystem...
(3/10) Creating labels...
(4/10) Adding run script...
(5/10) Setting ENV variables...
(6/10) Adding mount points...
(7/10) Fixing permissions...
(8/10) Stopping and removing the container...
(9/10) Building squashfs container...
Building image from sandbox: /tmp/ubuntu_14.04-2017-09-13-3e51deeadc7b.build
Building Singularity image...
Singularity container built: /tmp/ubuntu_14.04-2017-09-13-3e51deeadc7b.simg
Cleaning up...
(10/10) Moving the image to the output folder...
     62,591,007 100%  340.92MB/s    0:00:00 (xfr#1, to-chk=0/1)
Final Size: 60MB

and now the container can be inspected in various ways, default shows labels:

 singularity inspect ubuntu_14.04-2017-09-13-3e51deeadc7b.simg 
{
    "org.label-schema.singularity.build": "squashfs",
    "org.label-schema.docker.version": "17.06.2-ce",
    "org.label-schema.schema-version": "1.0",
    "org.label-schema.singularity.build-type": "docker2singularity",
    "org.label-schema.docker.id": "sha256:dea1945146b96542e6e20642830c78df702d524a113605a906397db1db022703",
    "org.label-schema.build-date": "2017-10-28-17:19:18",
    "org.label-schema.singularity.version": "2.4-dist",
    "org.label-schema.docker.created": "2017-09-13"
}

and then with different args (-e and -r) you can see the environment and runscript, respectively

singularity inspect --json -e -r ubuntu_14.04-2017-09-13-3e51deeadc7b.simg 
{
    "data": {
        "attributes": {
            "environment": "# Custom environment shell code should follow\n\n",
            "runscript": "#!/bin/sh\n/bin/bash $@\n"
        },
        "type": "container"
    }
}

@vsoch
Copy link
Member Author

vsoch commented Nov 1, 2017

ping!

@chrisgorgo
Copy link
Collaborator

Sorry for the late reply. I'm running into the following problem:

PS D:\drive\workspace\docker2singularity> docker run -ti --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock -v D:\singularity\:/output singularityware/docker2singularity:dev poldracklab/fmriprep

Image Format: squashfs
Inspected Size: 10760 MB

(1/10) Creating a build sandbox...
(2/10) Exporting filesystem...
tar: lib64: Directory renamed before its status could be extracted
tar: lib/systemd/system/timers.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/sysinit.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/sockets.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/sigpwr.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/resolvconf.service.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/rescue.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/reboot.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/poweroff.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/multi-user.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/local-fs.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/graphical.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/getty.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system/busnames.target.wants: Directory renamed before its status could be extracted
tar: lib/systemd/system: Directory renamed before its status could be extracted
tar: lib/systemd: Directory renamed before its status could be extracted
tar: lib: Directory renamed before its status could be extracted
tar: etc/xdg/systemd: Directory renamed before its status could be extracted
tar: etc/xdg: Directory renamed before its status could be extracted
tar: etc/systemd/system/timers.target.wants: Directory renamed before its status could be extracted
tar: etc/systemd/system/sysinit.target.wants: Directory renamed before its status could be extracted
tar: etc/systemd/system/multi-user.target.wants: Directory renamed before its status could be extracted
tar: etc/systemd/system/getty.target.wants: Directory renamed before its status could be extracted
tar: etc/systemd/system: Directory renamed before its status could be extracted
tar: etc/systemd: Directory renamed before its status could be extracted
tar: etc/sysctl.d: Directory renamed before its status could be extracted
tar: etc/ssl/certs: Directory renamed before its status could be extracted
tar: etc/ssl: Directory renamed before its status could be extracted
tar: etc/rcS.d: Directory renamed before its status could be extracted
tar: etc/rc6.d: Directory renamed before its status could be extracted
tar: etc/rc5.d: Directory renamed before its status could be extracted
tar: etc/rc4.d: Directory renamed before its status could be extracted
tar: etc/rc3.d: Directory renamed before its status could be extracted
tar: etc/rc2.d: Directory renamed before its status could be extracted
tar: etc/rc1.d: Directory renamed before its status could be extracted
tar: etc/rc0.d: Directory renamed before its status could be extracted
tar: etc/modules-load.d: Directory renamed before its status could be extracted
tar: etc/ld.so.conf.d: Directory renamed before its status could be extracted
tar: etc/fonts/conf.d: Directory renamed before its status could be extracted
tar: etc/fonts: Directory renamed before its status could be extracted
tar: etc/alternatives: Directory renamed before its status could be extracted
tar: etc: Directory renamed before its status could be extracted
tar: dev: Directory renamed before its status could be extracted
tar: bin: Directory renamed before its status could be extracted
tar: Exiting with failure status due to previous errors

This happens with -w as well, but does not happen when using current master.

@vsoch
Copy link
Member Author

vsoch commented Nov 10, 2017

Thanks @chrisfilo ! A few quick questions to help debug, since I don't have windows.

  1. Previously you indicated these images functioned as expected:
  • poldracklab/mriqc
  • ubuntu
  • continuumio/miniconda
  • bids/cpac

Did these all have the same error as you reported above?

  1. For the image poldracklab/fmriprep does it have issue with the whiteout files when used with regular singularity?

  2. For the entire list of images we've looked at:

  • poldracklab/mriqc
  • ubuntu
  • continuumio/miniconda
  • bids/cpac
  • poldracklab/fmriprep

Do you get the same error and failure on a linux host? I think this might be related to the filesystem or overlay fs, see these issues:

We also might want to consider the version of Docker running on the host:

We are having a release of 2.4.1 soon, and we might have a solution for the whiteout files, although not sure yet. Huge thanks for helping with the testing, the most important/relevant environment is Windows, and I don't think I'd know where to find it if I tried. And again please take the time you need to properly test!

@chrisgorgo
Copy link
Collaborator

Out of the list this is the only image I get this error for. I did not have a chance to try it on Linux.

What makes you think this is a Windows related issue? Have you tried to replicate it on your machine? The two issue you linked to were reported for Linux hosts.

As for .wh files I tried this but I run into another error:

[chrisgor@sh-101-58 ~]$  SINGULARITY_CACHEDIR=/tmp singularity pull -s 15307 --name /home/groups/russpold/singularity_images/poldracklab_fmriprep_test.img docker://poldracklab/fmriprep
WARNING: pull for Docker Hub is not guaranteed to produce the
WARNING: same image on repeated pull. Use Singularity Registry
WARNING: (shub://) to pull exactly equivalent images.
WARNING: Using the --size option when building from Docker Hub is deprecated.
WARNING: Container will be sized appropriately for Docker image.
Docker image path: index.docker.io/poldracklab/fmriprep:latest
Cache folder set to /tmp/docker
[48/48] |===================================| 100.0%
Importing: base Singularity environment
Importing: /tmp/docker/sha256:b3e1c725a85f0953e81815b7c7aabfad9ebfd90af53f99248981282b8045d787.tar.gz
Importing: /tmp/docker/sha256:4daad8bdde31f5969d6a44800e993a911bed25853b2f89417b07ce7f0ac67714.tar.gz
Importing: /tmp/docker/sha256:63fe8c0068a811103c702452985368fc99014f83b5f0151cf631644f13f383b2.tar.gz
Importing: /tmp/docker/sha256:4a70713c436f2350e8a9f1c1e6c823290f331254c6c21d5657056499d8575608.tar.gz
Importing: /tmp/docker/sha256:bd842a2105a862f62ba4ad726531029be49046c290307e9c07a688c89f4606e6.tar.gz
Importing: /tmp/docker/sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4.tar.gz
Importing: /tmp/docker/sha256:67664e735a306bf2beff64a5f8b3ffb22a3f48684cdf412fd93e8866f211fe0a.tar.gz
Importing: /tmp/docker/sha256:7f609af92f3a7ceb8134c5f278612a84f9558872ee2102fb0499266a1a6f5b4c.tar.gz
Importing: /tmp/docker/sha256:4649e39f3fb4cd5e4ebf9750a9b324fa0005056ebf076f70f9845f64adb2c5b9.tar.gz

gzip: /tmp/docker/sha256:4649e39f3fb4cd5e4ebf9750a9b324fa0005056ebf076f70f9845f64adb2c5b9.tar.gz: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

@0xaf1f
Copy link

0xaf1f commented Feb 13, 2018

Is there any update on this?

@vsoch
Copy link
Member Author

vsoch commented Feb 13, 2018

I think these bugs were present in earlier versions of 2.4 and may be resolved now (but in development branch) I think the best thing to do is to keep it in a branch for now (and @0xaf1f you should clone the branch and build the image freshly) to do your conversions (with the development version of singularity). When the next release goes out, we will make a corresponding branch (and only merge to be the "default" given no errors). It is my preference to only create the branches with official releases of some flavor, so having 2.4 here represent some stage of development doesn't seem ideal.

@vsoch
Copy link
Member Author

vsoch commented Feb 13, 2018

hey @0xaf1f I just threw together a docker2singularity that has the updated 2.4 (development) installed if you want to wait for it to build, and then try. --> https://hub.docker.com/r/vanessa/singularity/builds/ and probably faster to build on your own --> https://github.com/singularityhub/docker/blob/master/docker2singularity/Dockerfile.dev I'm going to be afk a bit but will be back if you have questions or want to work together, I didn't put much time into writing docs or testing.... :)

@0xaf1f
Copy link

0xaf1f commented Feb 13, 2018

I really appreciate it, @vsoch. Though I went on the route of creating a local registry and pulling from that, and it looks like it produced a good image.

@vsoch
Copy link
Member Author

vsoch commented Feb 13, 2018

hey, that works too! :)

@vsoch
Copy link
Member Author

vsoch commented May 30, 2018

Version 2.5 is released, so this PR is being closed as it wouldn't be ideal to merge into master. For those wanting docker2singularity for version 2.4, use the 2.4 branch: https://github.com/singularityware/docker2singularity/tree/v2.4

I will prepare a v2.5 branch soon.

@vsoch vsoch closed this May 30, 2018
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

Successfully merging this pull request may close these issues.

3 participants