[WIP] Setting up a per-container imageserver mapping #6724
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: littlejawa The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #6724 +/- ##
==========================================
+ Coverage 44.58% 44.62% +0.04%
==========================================
Files 127 127
Lines 14921 15051 +130
==========================================
+ Hits 6652 6716 +64
- Misses 7473 7538 +65
- Partials 796 797 +1 |
|
Any adjustments to man pages needed? |
24df7df to
859f860
Compare
|
force-push: fixing lint and vendor issues |
No, I don't think so. |
A new ImageServerList type is created, which is a map of ImageServers to containerIDs. Now rather than one single instance of ImageServer, we have possibly one per container. ImageServer can be registered along with their runtime implementation. The goal is to provide a way for some runtimes (e.g: peer-pods use case) to process the Image requests by relaying them to a remote VM, rather than having them executed on the local host. Signed-off-by: Julien Ropé <[email protected]>
- Fix tests according to previous changes - Adding unit tests for ImageServerList Signed-off-by: Julien Ropé <[email protected]>
as an ImageServer for kata containers. In Peer-pods use case, this ImageServer will be able to relay the relevant requests (PullImage typically) to the remote VM's agent, through the shim GRPC API. This specific implementation is yet to come. Signed-off-by: Julien Ropé <[email protected]>
859f860 to
eb37620
Compare
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@littlejawa: The following test failed, say
DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
There is a discussion going on regarding how cri-o support for confidential container can happen. Keeping this on hold as we're exploring other leads. |
|
A friendly reminder that this PR had no activity for 30 days. |
|
@littlejawa: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
Closing this PR since it had no activity in the past 90 days. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
In order to support the peer-pods use case, cri-o needs to be able to relay PullImage requests (at least), and probably other Image-related requests, to the remove VM used for running the container.
In the current implementation using kata containers, the way to do so is to call a new GRPC entry in the kata shim.
From cri-o's standpoint, that involves calling the runtimeVM instance for the container, when processing PullImage.
This PR provides a way to do that: it introduces a list of ImageServer instances, and provides a way to register a new ImageServer, associated to a containerID.
The current implementation of ImageServer is kept separately, as the "default ImageServer". It will be used for most of the workflow, to limit the overhead outside of peer-pods.
The registration of new ImageServer is done in the call to newRuntimeImpl(), where the runtime implementation is created, and where we can decide (depending on the type of runtime) whether or not a different ImageServer should be used, and link this ImageServer to the runtime.
I also included a very basic implementation of the ImageServer interface as part of the runtimeVM definition. This allows to use the runtimeVM object itself as ImageServer, and will simplify calling the kata shim process when performing image-related operations.
It is currently just a wrapper over the default ImageServer, and is used for testing only.
The registration in newRuntimeImpl() is commented out on purpose, and will be uncommented in a later PR, when the actual implementation of the PullImage forward will be done.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
NOTE: I have looked at #5624 which does something similar, but the association of ImageServer to runtimeVM is a requirement that it didn't have, and causes additional complexity. Discussing it with @alicefr, we agreed that I should try my own design.
Does this PR introduce a user-facing change?