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

powerpc support #5

Closed
lukasheinrich opened this issue Feb 20, 2020 · 7 comments
Closed

powerpc support #5

lukasheinrich opened this issue Feb 20, 2020 · 7 comments
Labels
question Further information is requested

Comments

@lukasheinrich
Copy link

Hi,

would sarus be expected to work on ppc64 machines, such as IBM HPCs? e.g. this docker image: ppc64le/centos

Thanks,
Lukas

@Madeeks Madeeks added the question Further information is requested label Feb 20, 2020
@Madeeks
Copy link
Member

Madeeks commented Feb 21, 2020

Hi Lukas,

we have not built or tested Sarus outside of Linux x86-64, which is also the target architecture of the standalone archive we distribute on GitHub releases.
In any case, the Sarus code does not contain x86-specific parts, and is pretty much architecture-agnostic, so it could probably work on Power architectures as well if compiled from source.
The hardest part may be building the dependencies (e.g. cpprestsdk or runc): https://sarus.readthedocs.io/en/stable/install/requirements.html
For reference, here is also the documentation about building Sarus from source: https://sarus.readthedocs.io/en/stable/install/installation.html#installing-from-source (edited)
Cheers,

Alberto

@lukasheinrich
Copy link
Author

runc should not be the problem, since I know containerd runs on power which should also use runc

this suggests cpprestsdk should also compile on power
microsoft/cpprestsdk#576

maybe it's worth looking into. Just to clarify, sarus is both daemon- and root-less?

Lukas

@Madeeks
Copy link
Member

Madeeks commented Feb 21, 2020

Sarus is indeed daemon-less, but requires root privileges to run containers, as detailed here.
The main reason for this is to allow mounting the container image as a loop device, preventing metadata thrashing when many containers access the same image on a parallel filesystem (for reference, see point 1. here).
Note that Sarus tries to be responsible with this power, performing several security checks to safekeep itself and the host system.

@lukasheinrich
Copy link
Author

given that runc can run rootless, would there be a possible mode to run in rootless mode (say if we have an unpacked flat filesystem as a rootfs)

@Madeeks
Copy link
Member

Madeeks commented Feb 24, 2020

It's not completely clear to me what's the use case you have in mind, could you please provide some more details?

Regarding the mount of the rootfs, there is an ongoing effort of benchmarking Squashfuse to understand the performance implications of such feature when applied to HPC deployments.

@haampie
Copy link

haampie commented Jul 11, 2020

@lukasheinrich if you mean rootless in the sense of user namespaces / user mapping (being root in the container, but without being root outside of it), I've tried it here: #15 and it seems to work more or less, but cgroups are still an issue.

@taliaga
Copy link
Collaborator

taliaga commented Nov 15, 2021

Closing issue because the question was answered and there is no clear next action to do. Feel free to reopen with further clarifications if needed.

@taliaga taliaga closed this as completed Nov 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants