-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[cli] graceful stop command #3968
Conversation
Change-Id: I1b1f9eecb666f5e3ca989ec0a7b46a3d9330ec67 Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
…sure that channel is subscribed when we subscribe for it Change-Id: I6b316f1ba2e2391e1793459406664365c095c924 Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
…stop introduced by #3892 Change-Id: Id131d3b2c334aabb38418213dbc2ac381dba8552 Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
if —force is used, then it is the same behaviour than before else by default a new action graceful-stop is called which calls the /api/system/stop and wait that the remote side is going into “READY_TO_SHUTDOWN” mode. after that the stop of containers is performed if auth is required, —user and —password can provide the auth data Change-Id: Ifea9bd32b0dfd2965e5365bc4ee54eb7c8714fc9 Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
Since this is a new feature then the release notes to have a deeper explanation and example. |
@TylerJewell ok I've updated release notes section |
what will happen if auth is not provided ? |
@riuvshin if auth is required it will tell you that you can't perform operation as you need authentication |
so maybe we have to add |
@riuvshin yes good catch |
@riuvshin what about cmd_stop in cmd_upgrade ? |
in @TylerJewell @benoitf wdyt guys? |
@riuvshin yes looks like the proper solution for me. So the user can decide if he performs a stop right now, delay it and do it with force or not |
Yes, I think that makes sense to me, too. |
… is the same behaviour than before else by default a new action graceful-stop is called which calls the /api/system/stop and wait that the remote side is going into “READY_TO_SHUTDOWN” mode. after that the stop of containers is performed Change-Id: Ibfd684a5f8fb17d13e8b86f42a10c76fe66a70dd Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
ok, I've added the changes |
I updated the release notes comment. |
Build success. https://ci.codenvycorp.com/job/che-pullrequests-build/1828/ |
What does this PR do?
Introduce graceful stop command for cli
by default,
stop
command is performing a graceful stop : stop all services then stop and remove containersusing
--force
the graceful stop is not done : we stop containers and remove containersauth can be used with
--user
and--password
What issues does this PR fix or reference?
#3886
Changelog and Release Note Information
Changelog
Add graceful stop (disable with --force) in CLI
Release Notes:
We have introduced a way to perform a graceful stop of Che. Previously, Che server stops would be timeout based, meaning that if any workspaces were running when the Che server was stopped, they would continue to run. We have introduced a graceful stop that will initiate shutdown of all workspaces before initiating a shutdown of the server. If workspaces are configured to auto-snapshot during stop, then graceful stop will wait for all workspaces to be snapped before stopping the server.
The default CLI
stop
command now performs a graceful stop. It stops all services then stops and remove containers. You can optionally add a--force
option to stop and remove containers without waiting for workspaces to stop. For authenticated servers like Codenvy, authentication can be provided by--user
and--password
.default graceful stop:
docker run ... eclipse/che stop
skip graceful stop:
docker run ... eclipse/che stop --force
use auth :
docker run ... eclipse/che stop --user <myemail> --password <my-secret>
Docs Pull Request
eclipse-che/che-docs#117
codenvy/docs#61