-
Notifications
You must be signed in to change notification settings - Fork 1.1k
oci/server: store container status in the container object #6026
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
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: haircommander The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
61c0d47 to
948b78d
Compare
the first thing WaitContainerStopped does is verifyPid(), so we can skip this. Signed-off-by: Peter Hunt <[email protected]>
Signed-off-by: Peter Hunt <[email protected]>
Signed-off-by: Peter Hunt <[email protected]>
Signed-off-by: Peter Hunt <[email protected]>
948b78d to
0d1ab0f
Compare
when a message is being sent over proto, it must not be edited. To circumvent this, the underlying memory section is not updated,
but the whole memory address with a changed copy.
Do this similarly for criStatus, which is a bit more involved, as there are more changing pieces.
In order to do so, we introduce Set{Started,Stopped} calls and wire them into runtime_oci.go. This way, we can return an updated
criStatus, but atomically change it so as to not corrupt proto's view of the world
Signed-off-by: Peter Hunt <[email protected]>
Signed-off-by: Peter Hunt <[email protected]>
Signed-off-by: Peter Hunt <[email protected]>
Signed-off-by: Peter Hunt <[email protected]>
when calling UpdateContainerStatus, in case some other fields get zero'd out Signed-off-by: Peter Hunt <[email protected]>
0d1ab0f to
005589b
Compare
|
A friendly reminder that this PR had no activity for 30 days. |
|
@haircommander: 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. |
|
@haircommander: 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. |
|
@haircommander: 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. |
|
@haircommander what's the status of this PR? It's good to have these changes. |
yeah they seem like good changes though the PR needs some work. I don't think it's very high priority right now as the underlying issue was resolved |
|
A friendly reminder that this PR had no activity for 30 days. |
|
/remove-lifecycle stale |
|
A friendly reminder that this PR had no activity for 30 days. |
|
Closing this PR since it had no activity in the past 90 days. |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
this is part follow up of #5672, part alternative to #6023.
This came from investigation of #6023. Basically, it seems createdAt is subject to change because we return what is directly in the state. This got me thinking that we shouldn't be updating createdAt, finishedAt or startedAt, as they should be static.
That, paired with the effort in #5672 to reduce the number of new objects that are created, lead to this!
The idea is we know exactly when states change for containers. In UpdateContainerSTatus calls after we catch an exit, we know the time of exit, we know when we created the container and when we started it. Consulting
runc updateand updating our state can leave us in weird situations (like that in kubernetes/kubernetes#105332 and https://bugzilla.redhat.com/show_bug.cgi?id=2094865).Overall, this should make the flow simpler, and the number of objects created lower, at the cost of a decently heavy refactor.
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?