-
Notifications
You must be signed in to change notification settings - Fork 3.8k
sandbox: Move CRI Image Service and CRI Base seperate plugins #9391
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
Conversation
|
Hi @abel-von. Thanks for your PR. I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
4c29c26 to
0efc665
Compare
|
All the integration test cases fail. I think there is regression caused by 09723a6 |
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com> Signed-off-by: Abel Feng <fshb1988@gmail.com>
0efc665 to
ebb1655
Compare
|
I think it is not caused by 09723a6. It is actually because we changed the cri plugin type from I think we may have to keep the |
|
I think the CRI integration test passed, one of them failed because an occasional failure of the container registry. could you please rerun it to make sure all CI steps green? @fuweid |
pkg/cri/cri.go
Outdated
| ID: "cri", | ||
| Config: &config, | ||
| Type: plugins.GRPCPlugin, | ||
| ID: "cri-grpc-service", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you just keep it as cri? It's unlikely to do live-migration because the running containers are using the volume in this plugin folder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably need to add some release upgrade integration cases for this before we accept this.
REF:
| // Add exec/stats/stop-existing-running-pods/... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you just keep it as
cri? It's unlikely to do live-migration because the running containers are using the volume in this plugin folder.
That is actually why the intergration test failed before. So that I add a commit 9a18e8e to keep the plugin folder path "io.containerd.grpc.v1.cri" as before.
I think it is no use to change the name here because we want to add a plugin of type io.containerd.internal.v1 to carry the cri configs and other plugins will be depend on this plugin to get the cri configs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably need to add some release upgrade integration cases for this before we accept this.
added a test case to manipulate the containers in the pod before upgrade. 0597be4849
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The added integration test case reveals an existing compatibility issues, and I fixed in e18e86905b3071, all these are included in this PR, could you please take a look at the new commits ?
or, as Max has approved, shall I put the two new commits in a new PR? @mxpv @fuweid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't need to rename it cri-grp-service. Just use cri because it's grpc plugin. It won't conflict with internal one.
75820ea to
0597be4
Compare
mikebrow
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good .. yes, suggest splitting up the test and fix (last two commits) into another PR .. tag that PR for cherry pick..
e18e869 to
9a18e8e
Compare
fuweid
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically, it looks good to me
pkg/cri/cri.go
Outdated
| ID: "cri", | ||
| Config: &config, | ||
| Type: plugins.GRPCPlugin, | ||
| ID: "cri-grpc-service", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't need to rename it cri-grp-service. Just use cri because it's grpc plugin. It won't conflict with internal one.
| } | ||
| } | ||
|
|
||
| // For backward compatibility, we have to keep the rootDir and stateDir the same as before. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's not a long-term solution. We should introduce some toggle to switch to use cri.base root or state dir in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's not a long-term solution. We should introduce some toggle to switch to use cri.base root or state dir in the future.
we may have to record the root and state dir in the sandbox object in cri cache, when recovering from restart, we need to detect if it is "io.containerd.internal.v1.cri" or "io.containerd.grpc.v1.cri", but this is a big change, can we leave it in another PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't need to rename it cri-grp-service. Just use cri because it's grpc plugin. It won't conflict with internal one.
changed back to "cri"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we may have to record the root and state dir in the sandbox object in cri cache, when recovering from restart, we need to detect if it is "io.containerd.internal.v1.cri" or "io.containerd.grpc.v1.cri", but this is a big change, can we leave it in another PR?
Yes. We can handle it in the follow-up. I am not against to introduce fallback logic to handle existing running pods. 😂
Signed-off-by: Abel Feng <fshb1988@gmail.com>
Signed-off-by: Abel Feng <fshb1988@gmail.com>
Signed-off-by: Abel Feng <fshb1988@gmail.com>
9a18e8e to
e1b4958
Compare
fuweid
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR cherry-picked the #9119 and split the CRI plugin into plugins below:
io.containerd.internal.v1.criplugin is for loading cri configuration and validationio.containerd.image.v1.cri-image-serviceplugin is a image service to create/pull/remove/query images.io.containerd.sandbox.controller.v1.podsandboxthe a sandbox controller implement that create a pause container to mimic a sandbox, it is a legacy support.io.containerd.grpc.v1.cri-grpc-serviceis the CRI grpc service plugin, to serve grpc API calls of CRI interfaces.