You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just a heads up, we have a k8s SIG-Node WG that is considering significant changes to the CRI around image services.
Security image access policies, authentication with in proc local key rings vs over the RPC, GC cache polices, support for runtime handlers in the image service layer that choose which image to unpack from the image index (windows platform versions etc.,) and which snapshotter to use one per runtime handler, ...
For these and a number of other reasons we should chat about other potential ways to hook into the image services api.
Thought:
extend the NRI to support image services at the CRI layer (something we've already been considering)
some other way to extend sandboxes/the internal core image service tooling to support needed extension points
The text was updated successfully, but these errors were encountered:
Hi @mikebrow thanks for the heads up. Is there a link or any documents that give more context around the proposed changes? I haven't been following too closely to the newer NRI / sandbox APIs but I'm happy to chat to learn more. I've contacted you on LinkedIn.
Just a heads up, we have a k8s SIG-Node WG that is considering significant changes to the CRI around image services.
Security image access policies, authentication with in proc local key rings vs over the RPC, GC cache polices, support for runtime handlers in the image service layer that choose which image to unpack from the image index (windows platform versions etc.,) and which snapshotter to use one per runtime handler, ...
For these and a number of other reasons we should chat about other potential ways to hook into the image services api.
Thought:
The text was updated successfully, but these errors were encountered: