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

skopeo: add wrapper #87659

Merged
merged 2 commits into from May 13, 2020
Merged

skopeo: add wrapper #87659

merged 2 commits into from May 13, 2020

Conversation

@zowoq
Copy link
Contributor

zowoq commented May 12, 2020

Motivation for this change
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
@edef1c
Copy link
Member

edef1c commented May 12, 2020

This doesn't describe at all what purpose the wrapper / this PR serves.

zowoq added 2 commits May 11, 2020
wrap fuse-overlayfs for storage compatibility with the podman wrapper
@nlewo
Copy link
Member

nlewo commented May 12, 2020

@GrahamcOfBorg test docker-tools

@nlewo
Copy link
Member

nlewo commented May 12, 2020

It would be nice to set the path at build time, to avoid this wrapper. I created the issue containers/storage#622 to track this.

@nlewo
nlewo approved these changes May 12, 2020
Copy link
Member

vdemeester left a comment

LGTM 🐯

@nlewo
Copy link
Member

nlewo commented May 12, 2020

We could actually build a storage.conf file with the path of the fuse-overlay binary and make this file the default one at build time.

@zowoq
Copy link
Contributor Author

zowoq commented May 13, 2020

We could actually build a storage.conf file with the path of the fuse-overlay binary and make this file the default one at build time.

If we change the default path to this file at build time will it still read from /etc/containers/storage.conf as well?

@nlewo
Copy link
Member

nlewo commented May 13, 2020

@zowoq No, Skopeo will not read the /etc/containers/storage.conf file anymore (as it is already the case for the default policy file).

@zowoq
Copy link
Contributor Author

zowoq commented May 13, 2020

No, Skopeo will not read the /etc/containers/storage.conf file anymore

I don't think that it is a good solution then. /etc/containers/storage.conf is used by other programs (and will probably end up being managed by the virtualization.containers module) and I don't think it should be ignored.

(as it is already the case for the default policy file).

The policy file can now be managed by the virtualization.containers module which presents another problem.

@nlewo
Copy link
Member

nlewo commented May 13, 2020

But we can still change the policy file path on CLI which doesn't seem to be possible for the storage.conf file. Moreover, if rootless is enabled, our storage.conf file will not be used.
So, forget what I said and let's do it with the wrapper.

@nlewo
Copy link
Member

nlewo commented May 13, 2020

docker-tools tests depending on Skopeo works fine.

@nlewo nlewo merged commit a29c774 into NixOS:master May 13, 2020
18 checks passed
18 checks passed
tests.docker-tools on x86_64-linux Failure
Details
Evaluation Performance Report Evaluator Performance Report
Details
fuse-overlayfs, fuse-overlayfs.passthru.tests, skopeo, skopeo.passthru.tests on aarch64-linux Success
Details
fuse-overlayfs, fuse-overlayfs.passthru.tests, skopeo, skopeo.passthru.tests on x86_64-linux Success
Details
grahamcofborg-eval ^.^!
Details
grahamcofborg-eval-check-maintainers matching changed paths to changed attrs...
Details
grahamcofborg-eval-check-meta config.nix: checkMeta = true
Details
grahamcofborg-eval-darwin nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="f01d716"; rev="f01d7164a866551001cefbe61d328f20907b2f70"; } ./pkgs/t
Details
grahamcofborg-eval-lib-tests nix-build --arg pkgs import ./. {} ./lib/tests/release.nix
Details
grahamcofborg-eval-nixos nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="f01d716"; rev="f01d7164a866551001cefbe61d328f20907b2f70"; } ./nixos/
Details
grahamcofborg-eval-nixos-manual nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="f01d716"; rev="f01d7164a866551001cefbe61d328f20907b2f70"; } ./nixos/
Details
grahamcofborg-eval-nixos-options nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="f01d716"; rev="f01d7164a866551001cefbe61d328f20907b2f70"; } ./nixos/
Details
grahamcofborg-eval-nixpkgs-manual nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="f01d716"; rev="f01d7164a866551001cefbe61d328f20907b2f70"; } ./pkgs/t
Details
grahamcofborg-eval-nixpkgs-tarball nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="f01d716"; rev="f01d7164a866551001cefbe61d328f20907b2f70"; } ./pkgs/t
Details
grahamcofborg-eval-nixpkgs-unstable-jobset nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="f01d716"; rev="f01d7164a866551001cefbe61d328f20907b2f70"; } ./pkgs/t
Details
grahamcofborg-eval-package-list nix-env -qa --json --file .
Details
grahamcofborg-eval-package-list-no-aliases nix-env -qa --json --file . --arg config { allowAliases = false; }
Details
tests.docker-tools on aarch64-linux Success
Details
@zowoq zowoq deleted the zowoq:skopeo branch May 13, 2020
@zowoq
Copy link
Contributor Author

zowoq commented May 13, 2020

@nlewo Would you have an objection if I sent a PR to remove setting the policy at build time?

It's not very clear (and somewhat surprising TBH) that the config in /etc/containers/policy.json will be silently ignored unless skopeo --policy /etc/containers/policy.json is used.

skopeo does throw a fairly clear error if the file doesn't exist and has an --insecure-policy option to ignore the error.

@nlewo
Copy link
Member

nlewo commented May 14, 2020

@zowoq When there is no /etc/containers/policy.json file, will skopeo still be working without having to manually specifying it?

@zowoq
Copy link
Contributor Author

zowoq commented May 14, 2020

Without a policy file it will stop working but passing --insecure-policy will allow it to work.

@nlewo
Copy link
Member

nlewo commented May 14, 2020

The user who wants to use Skopeo from nixpkgs would then have to understand what this flag means and why it is needed. So, this is a bit annoying...
What about opening an issue on Skopeo to ask if it could work without this file?

@zowoq
Copy link
Contributor Author

zowoq commented May 14, 2020

What about opening an issue on Skopeo to ask if it could work without this file?

This file is used by other tools so I don't see how upstream could special case this tool to work without it by default.

@zowoq
Copy link
Contributor Author

zowoq commented May 14, 2020

I've opened #87821, we can continue discussion there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.