Pre-create config manipulation?

[wking]

There's been a lot of discussion over in opencontainers/runc#1811 about how to support the NVIDIA folks and others who want to be able to create devices (possibly after having loaded kernel modules) and bind userspace libraries into the container. Currently that's happening in the middle of run's create-time mount handling before the container pivots to its new root directory with runc's incorrectly-timed prestart hook trigger (opencontainers/runc#1710). My preferred approach would be to have a directory with runtime-config filters (in the stdin/stdout filter sense) to allow trusted parties to manipulate the config JSON before calling the runtime's create. I've mocked up a proof-of-concept runtime wrapper here. I'd like to get something like this landed in libpod (maybe here?). Is there enough interest among libpod maintainers for it to be worth me spending some time putting that together (you can always reject it once you see it ;), or can you already reject the proposal now based on the proof-of-concept?

[mheon]

Overall, I think this is probably a fine addition, with a few caveats. I am a bit concerned about potential performance hits here (a lot of fork-exec during one of the most expensive operations in Podman/CRI-O). I think we definitely want a way of only calling the filter programs selectively (similar to the OCI hooks). I'm also thinking this needs to come with a long disclaimer about how even simple changes to the OCI spec can cause containers to explode without warning, to try and reduce the number of bug reports we get about faulty plugins generating unusable configs.

…

On Mon, Nov 19, 2018, 01:21 W. Trevor King ***@***.*** wrote: There's been a lot of discussion over in opencontainers/runc#1811 <opencontainers/runc#1811> about how to support the NVIDIA folks and others who want to be able to create devices (possibly after having loaded kernel modules) and bind userspace libraries into the container. Currently that's happening in the middle of run's create-time mount handling before the container pivots to its new root directory with runc's incorrectly-timed prestart hook trigger (opencontainers/runc#1710 <opencontainers/runc#1710>). My preferred approach <https://groups.google.com/a/opencontainers.org/forum/#!msg/dev/pWEp_UK6aAk/6_nHAypqAQAJ> would be to have a directory with runtime-config filters (in the stdin/stdout filter sense) to allow trusted parties to manipulate the config JSON before calling the runtime's create. I've mocked up a proof-of-concept runtime wrapper here <https://github.com/wking/libpod/tree/config-filters>. I'd like to get something like this landed in libpod (maybe here <https://github.com/containers/libpod/blob/v0.11.1.1/libpod/container_internal.go#L609>?). Is there enough interest among libpod maintainers for it to be worth me spending some time putting that together (you can always reject it once you see it ;), or can you already reject the proposal now based on the proof-of-concept <https://github.com/wking/libpod/tree/config-filters>? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1828>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHYHCH_ZF7PyCwk8M25LIpcN8tLHZqsXks5uwk4CgaJpZM4YoeXT> .

[rhatdan]

I agree, this has to be optional by configuration. We also need information back in podman info to tell us whether one of these is installed.

[wking]

I agree, this has to be optional by configuration.

The in-flight #1830 already has that covered.

We also need information back in podman info to tell us whether one of these is installed.

Can someone give me some pointers on this. I dunno how info is fed, and I dunno what sort of information you're looking for. Do we already list matching hooks there for other stages?

[mheon]

I think what you're already doing in #1830 (reporting literal changes to the spec) is plenty sufficient - should be enough to clue us in if anything goes wrong.