add network.allocate_ip option to allow for rootless CNI bridge utilisation

[PauloMigAlmeida]

This PR is for a very specific scenario which has happened with me recently.

My scenario: I got access to server in which I do know (and will not possess) a privileged user and yet, I need set up the environment using singularity-composer.

It turns out that the only step in which fakeroot (for obvious reasons) won't suffice is to attach the allocated IP to a running container because that requires real root access (or at least CAP_NET_*).

So if we allow the user to run the services without allocating IPs then it can run without needing a priviledge used...something like this (fictitious example)

singularity run --bind ./env/postgres_env.sh:/.singularity.d/env/postgres_env.sh --bind ./postgres_data:/var/lib/postgresql/data --bind ./postgres_run:/var/run/postgresql  --fakeroot--net --network-args "portmap=5432:5432/tcp" --hostname cvatdb /home/paulo/workspace/cvat/singularity/cvatdb.sif

[vsoch]

For the test errors - this goes back to the sylabs name switch. I can either update the version or if you want to edit the file, if you go up to 3.8.1 ish I think it should work!

/home/circleci/singularity/3.5.0/bin:/tmp/go/bin:/tmp/go/bin:/home/circleci/conda/Python3/bin:/opt/circleci/.nvm/versions/node/v6.1.0/bin:/opt/circleci/.rvm/gems/ruby-2.3.1/bin:/opt/circleci/.rvm/gems/ruby-2.3.1@global/bin:/opt/circleci/.rvm/rubies/ruby-2.3.1/bin:/home/circleci/.go_workspace/bin:/usr/local/go/bin:/opt/circleci/.pyenv/shims:/opt/circleci/.pyenv/bin:/opt/google-cloud-sdk/bin:/usr/local/apache-maven/bin:/home/circleci/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/gradle-1.10/bin:/opt/circleci/.rvm/bin:/opt/circleci/.rvm/bin
--2021-09-27 22:05:55--  https://github.com/sylabs/singularity/releases/download/v3.5.0/singularity-3.5.0.tar.gz
Resolving github.com (github.com)... 140.82.114.4
Connecting to github.com (github.com)|140.82.114.4|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-09-27 22:05:55 ERROR 404: Not Found.


Exited with code exit status 8

It should be in .circleci/config.yaml.

[vsoch]

You'll also want to run black on the code for the formatting.

[PauloMigAlmeida]

Thanks @vsoch I will tweak the circleci config until I get it to work :)

[vsoch]

I think perhaps you forgot to save the circle config?

[PauloMigAlmeida]

🤦🏼‍♂️ That makes sense, I must be blind today lol

[vsoch]

I actually do that all the time - don't push control S hard enough and I forget to push one of my changes!

[PauloMigAlmeida]

It seems like the latest version I can point the org to is 3.7.3...any release beyond that has the asset file name changed from singularity-<version>.tar.gz to singularity-ce-<version>tar.gz

I will play with that more after lunch, thanks for the help vanessa

[vsoch]

Looks like the circle config needs a bit more work:

make: Entering directory `/go/src/github.com/sylabs/singularity/builddir'
 GEN /go/src/github.com/sylabs/singularity/scripts/go-generate
 GO singularity
    [+] GO_TAGS "containers_image_openpgp sylog oci_engine singularity_engine fakeroot_engine apparmor selinux seccomp"
# github.com/seccomp/libseccomp-golang
../vendor/github.com/seccomp/libseccomp-golang/seccomp_internal.go:26:2: error: #error Minimum supported version of Libseccomp is v2.2.0
 #error Minimum supported version of Libseccomp is v2.2.0

If you can figure out a fix, that's great, but this is out of scope for what you are doing here, so feel free to wait for me to debug - I can probably make some time over the weekend.

In the meantime, we can still discuss the design here! A quick question I have is - is there any reason to have this as a command line param instead of an option or similar in a singularity-compose.yaml? Either we would have one or the other (for some logical reason) or both. I'm leaning towards having it in the yaml (and removing the command line option) unless this use case is special.

And the only other things beyond that will be to run formatting with black, and then add some notes to the documentation for what is the final implementation.

[vsoch]

@PauloMigAlmeida sounds good! I'm thinking we might need a new release of the circle orb (that I own and can do) but probably won't be able to do it until the weekend.

[vsoch]

okay I have a new orb to test - singularity/singularity@dev:alpha if you want to update and push once, I can keep re-running to test things out (I just updated the default singularity version so you can remove your changes there) and I suspect I'll need to debug the libseccomp issue.

[PauloMigAlmeida]

If you can figure out a fix, that's great, but this is out of scope for what you are doing here, so feel free to wait for me to debug - I can probably make some time over the weekend.

Let me know if I can be of any assistance, I'm happy to help.

is there any reason to have this as a command line param instead of an option or similar in a singularity-compose.yaml?

Good point. I thought that adding it as an item on start -> options array could be considered misleading as these are mainly singularity options such as --fakeroot, --net and so on. So given that this is behaviour specific to singularity-compose tool, I thought the natural approach would be to follow the --no-resolv footsteps.

Tbh, I'm flexible with the implementation though... what would you prefer?

okay I have a new orb to test - singularity/singularity@dev:alpha

Done

[vsoch]

Thank you! I should be able to test it from here!

I do agree it's different/ separate from a singularity option. I think my question would be - is this something that you'd want to maintain with your singularity-compose.yaml (e.g., could the same recipe be run with and without this flag so it shouldn't be kept with the recipe itself?) If it's a consistent thing that is always needed, then I think it should be in the singularity-compose too. What about something like a network group? E.g.,

version: "2.0"
instances:
  app:
    build:
      context: ./app
    network:
      allocate_ip: false # defaults to true

[PauloMigAlmeida]

On the code format subject, you may have come across with this one too.

When running black --check scompose but using the latest available version everything works out.

[paulo@localhost singularity-compose]$ black --check scompose
All done! ✨ 🍰 ✨
27 files would be left unchanged.
[paulo@localhost singularity-compose]$ pip uninstall black
Uninstalling black-21.9b0:
  Would remove:
    <redacted>
Proceed (y/n)? y
  Successfully uninstalled black-21.9b0

The error only happens when using the version <= 19.10b0

[paulo@localhost singularity-compose]$ black --check scompose
would reformat /home/paulo/workspace/singularity-compose/scompose/client/__init__.py
Oh no! 💥 💔 💥
1 file would be reformatted, 26 files would be left unchanged.

I installed the version on that circle ci is installing via conda (so everything works out) but in case this happens in the future, you know why =)

[vsoch]

Ah thank you! Yes this has definitely happened to me before as well - black is a moving target!

[PauloMigAlmeida]

I do agree it's different/ separate from a singularity option. I think my question would be - is this something that you'd want to maintain with your singularity-compose.yaml (e.g., could the same recipe be run with and without this flag so it shouldn't be kept with the recipe itself?) If it's a consistent thing that is always needed, then I think it should be in the singularity-compose too. What about something like a network group? E.g.,

You are right, this should be kept at the compose.yml file which would be applied at the instance level rather than globally. I will change my implementation.

[vsoch]

okay I've tried everything that makes sense to no avail - I'm going to need to add for help from Sylabs on this one! Don't let the failing CI stop you from working on this - we will get it working soon!

[PauloMigAlmeida]

Thanks @vsoch! I changed the implementation to match the yaml structure that you suggested. Let me know if you have any comments on that

[vsoch]

okay posted an issue, hopefully will get some help! sylabs/singularity#338

[vsoch]

It looks great! So we will just be waiting on the circle build - and I opened an issue on the Sylabs repo to ask for help about this error. If they don't have insight, I'll just try installing the correct version of libseccomp from source and call it a day. But hopefully they will have seen this error before.

The only remaining thing to do for approval on the PR is to add notes to the docs about this field group. I think the most straight forward thing would be to add a "Network Group" section after "Network" here: https://github.com/singularityhub/singularity-compose/blob/master/docs/spec/spec-2.0.md#networking that explains the very simple options we currently have.

[PauloMigAlmeida]

It looks great! So we will just be waiting on the circle build

Sweet,

The only remaining thing to do for approval on the PR is to add notes to the docs about this field group.

Just added a paragraph there, let me know if you want me to change anything

[vsoch]

okay I can't figure it out - I'm going to have to refactor the entire CI this weekend to not use the orb, it's beyond me why I'm getting this older kernel and what looks to be an ABI issue. Sorry for the slowness, and thanks for letting me test on this PR!

[vsoch]

All is working! Docs look great, thanks for the changes.

[vsoch]

https://pypi.org/project/singularity-compose/0.1.10/

[PauloMigAlmeida]

Super! 🎉 thanks a lot @vsoch