-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Implement Container States #311
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
|
Build failure libcontainer/container_linux.go:827: unreachable code |
|
I like the idea of a |
c3e7e40 to
1b014f6
Compare
libcontainer/container_linux.go
Outdated
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.
@crosbymichael
Do we depend on config frozen state(paused), I thought checking cgroup subsystem for the specific container would get the right state for freezer subsystem ?
or
As with your new changes, you are transitioning the state, can we leverage the state that instead of checking configs ( where Frozen never set in our configs while starting the container)
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.
ya, we need to get your commits in #218 to resolve this.
|
@crosbymichael |
libcontainer/state_linux.go
Outdated
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.
If the user checkpointed in different directory, I'm not sure whether that will get cleaned. This forces to run the checkpoint and restore from the same place ( which is expected) but the user does some mistake if the checkpoint directory exists ( not cleaned) it will pick up that image for restoring ?
Few times I faced the problem in this area.
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 believe this is correct. That is not the checkpointed files but just a marker that the container was checkpointed. It will be removed like all the state after the container stops.
libcontainer/container_linux.go
Outdated
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.
s/inprocess/in process/
1b014f6 to
a232e4f
Compare
|
@mrunalp updated |
libcontainer/state_linux.go
Outdated
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.
Why do we need the base here? From the patch it looks like we are using it for calling destroy on destroyed state. Could we have a common destroy helper function and call it from destroy() of runningState/destroyState instead?
a232e4f to
e797abd
Compare
|
@LK4D4 ping |
libcontainer/container_linux.go
Outdated
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.
Looks like you don't need else here
|
Code looks logical for me. I posted some style recommendations though. |
c080be2 to
6afa5f3
Compare
|
@LK4D4 updated thanks for the reivew |
|
@crosbymichael I think maybe it's possible to write some tests. Maybe simple unit-tests for transitions. |
|
This looks fine to me. Could we rearrange the commits a bit before we merge (once all comments are addressed) ? |
|
Needs rebase. Otherwise looks fine. |
|
Yeah, LGTM in advance |
1ad4e22 to
31f7b06
Compare
|
@LK4D4 updated and squashed |
|
@mrunalp i squashed the commits for you ;) |
|
@crosbymichael LGTM. I didn't really want you to have to squash to 1 :D (Just meant no big addition deletion over the series). |
|
@mrunalp yeah, maybe unsquash now... |
|
noooooo |
f8ac1b5 to
03f07c8
Compare
Signed-off-by: Michael Crosby <[email protected]> Add state status() method Signed-off-by: Michael Crosby <[email protected]> Allow multiple checkpoint on restore Signed-off-by: Michael Crosby <[email protected]> Handle leave-running state Signed-off-by: Michael Crosby <[email protected]> Fix state transitions for inprocess Because the tests use libcontainer in process between the various states we need to ensure that that usecase works as well as the out of process one. Signed-off-by: Michael Crosby <[email protected]> Remove isDestroyed method Signed-off-by: Michael Crosby <[email protected]> Handling Pausing from freezer state Signed-off-by: Rajasekaran <[email protected]> freezer status Signed-off-by: Rajasekaran <[email protected]> Fixing review comments Signed-off-by: Rajasekaran <[email protected]> Added comment when freezer not available Signed-off-by: Rajasekaran <[email protected]> Signed-off-by: Michael Crosby <[email protected]> Conflicts: libcontainer/container_linux.go Change checkFreezer logic to isPaused() Signed-off-by: Michael Crosby <[email protected]> Remove state base and factor out destroy func Signed-off-by: Michael Crosby <[email protected]> Add unit test for state transitions Signed-off-by: Michael Crosby <[email protected]>
03f07c8 to
4415446
Compare
|
@crosbymichael Yeah, it was a joke about unsquash. |
|
LGTM |
style: remove unicode character
One of the most complex parts of the container are the various states that it has. Pause, running, stopped, destroyed, checkpointed, resumed, etc. Transitioning to these various states are also complex. Right now we use various methods to figure out what state the container is in and not really where it was. There is a good pattern to follow when you have to deal with states and transitions.
For each of the container states there is a separate type. Right now most of the logic is around how to destroy the container and depending on the state what to remove on disk. By moving all the destroy logic to the state types and letting them handle what other states they are able to transition to this it reduces the complexity when figuring out the transitions even if it is a little more code and more types.
In the future we can move more of the container methods to the state types to better handle the error conditions and remove some of the if blocks in things like
Start().Let me know what you all think. This is part of the work making runc work with the new State type from the specs. Alot of the logic was spread out around
Destory()in runc and libcontainer and this centralizes all that logic and handles all the changes properly no matter what combination.Closes #218