rollup issue for experimental-image-proxy

[cgwalters]

#1476 merged, but there's more we can/should do as followup.

• Add CI to skopeo that exercises it. I've been testing via the unit tests in https://github.com/ostreedev/ostree-rs-ext/ - we could wire that up as "reverse dependency testing". Or, maybe it wouldn't be hard to write a simple client in e.g. Python and just run it directly here?
• Validate that e.g. signed images work correctly
• Add support for privilege dropping (in particular I'd like to avoid running the proxy as real root/CAP_SYS_ADMIN when used for host OS updates with ostree); we'd need to do something like open e.g. ~/.docker/config.json or equivalent privileged, then re-exec? Or maybe just have the caller open the required creds, pass them via fd and use --authfile /proc/self/fd/X or so)
• Add an API that fetches the config object too?
• It turns out that in order to fetch from containers-storage: we may need the config so we can use the diffids

[lsm5]

@cevich @edsantiago PTAL RE: ci ^

[cevich]

Add CI to skopeo that exercises it.

I'm always in favor of more testing 😁

I've been testing via the unit tests in https://github.com/ostreedev/ostree-rs-ext/ - we could wire that up as "reverse dependency testing".

Though my general opinion is against reverse-dependency testing, since they can be a PITA to maintain. However, if it makes sense and you go this route, it should run as a separate Cirrus-CI task (i.e. not test_skopeo_task) - since (surprise!) this test is also used in reverse-dependency testing for containers/image - in other words, that would hurt my brain 😁

Or, maybe it wouldn't be hard to write a simple client in e.g. Python and just run it directly here? Validate that e.g. signed images work correctly

Python3 is available in these environments. If it can be a simple client, this would be easier to incorporate into test_skopeo_task - meaning you get testing under containers/image for "free" (minus the brain-hurt).

Add support for privilege dropping (in particular I'd like to avoid running the proxy as real root/CAP_SYS_ADMIN when used for host OS updates with ostree); we'd need to do something like open e.g. ~/.docker/config.json or equivalent privileged, then re-exec? Or maybe just have the caller open the required creds, pass them via fd and use --authfile /proc/self/fd/X or so)

There is an existing setup in podman's CI for creating a test-user, and re-exec'ing the tests via ssh It's a bit more convoluted than privilege dropping, runuser, or su, but lets the tests run from a real login-shell environment. This may be important, since it's closer to what real-users will experience.

Add an API that fetches the config object too? It turns out that in order to fetch from containers-storage: we may need the config so we can use the diffids

I'm not sure what this means. However it may be worth getting some sort of basic testing in place before worrying about additional features (which need more tests).

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@cgwalters @cevich @mtrmac What is going on with this issue?

[cevich]

I'm in favor of the "simple python client" idea, testing here, and getting "for free" testing in containers/image. I'm not in favor of doing the test-writing work myself 😁 (though I'm willing to help with the automation part, as always).

[cgwalters]

#1495
already did some of this, but not all.

I think we definitely need testing for signed images, but...dunno. Closing this for now, I will track signed image bits over in ostreedev/ostree-rs-ext#163