Skip to content
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

sct docker backend deletes all docker instances on the system in teardown #9027

Closed
asias opened this issue Oct 23, 2024 · 7 comments · Fixed by #9235
Closed

sct docker backend deletes all docker instances on the system in teardown #9027

asias opened this issue Oct 23, 2024 · 7 comments · Fixed by #9235
Assignees
Labels
Bug Something isn't working right

Comments

@asias
Copy link
Contributor

asias commented Oct 23, 2024

It should only delete instances started by sct test, not all instances on the system.

< t:2024-10-23 02:04:54,597 f:remote_base.py  l:560  c:RemoteLibSSH2CmdRunner p:DEBUG > <172.18.0.5>: Running command "docker ps -a -q | xargs docker rm -f"...
@asias
Copy link
Contributor Author

asias commented Oct 23, 2024

Got another example:

< t:2024-10-23 07:00:20,328 f:cluster.py      l:1998 c:sdcm.cluster_docker  p:INFO  > Node perf-latency-nemesis-asias-monitor-node-da4ee3ad-0 [127.0.0.1 | 127.0.0.1]: Installing Scylla...                                                                                                                                                                                                                                                                                   We trust you have received the usual lecture from the local System                                                                                                                                                                     Administrator. It usually boils down to these three things:                                                                                                                                                                                                                                                                                                                                                                                                                       #1) Respect the privacy of others.                                                                                                                                                                                                     #2) Think before you type.                                                                                     
    #3) With great power comes great responsibility.        

@asias asias removed their assignment Oct 24, 2024
@fruch
Copy link
Contributor

fruch commented Nov 12, 2024

this one goes way back when YCSB was introduced for alternator

f971bb9

that code was written assuming it runs on a loader node, so docker backend running locally wasn't considered.

we should overwrite kill_docker_loaders for docker backend, and kill more selectively based on the test_id label we should have to the docker run (and and we are missing them, we should introduce those labels for the stress docker instances)

@fruch fruch assigned dimakr and unassigned fruch Nov 12, 2024
@fruch fruch added the Bug Something isn't working right label Nov 12, 2024
@dimakr
Copy link
Contributor

dimakr commented Nov 15, 2024

@fruch
Not sure that the command docker ps -a -q | xargs docker rm -f deletes containers on the system as the only place where it is executed is

loader.remoter.run(cmd='docker ps -a -q | xargs docker rm -f', verbose=True, ignore_status=True)

I.e. in case of docker backend it is requested to be executed in a loader container, not in the on the SCT runner (local host).

@fruch
Copy link
Contributor

fruch commented Nov 15, 2024

@fruch
Not sure that the command docker ps -a -q | xargs docker rm -f deletes containers on the system as the only place where it is executed is

loader.remoter.run(cmd='docker ps -a -q | xargs docker rm -f', verbose=True, ignore_status=True)

I.e. in case of docker backend it is requested to be executed in a loader container, not in the on the SCT runner (local host).

There's one docker engine on the host, regardless where you give the command from.

So when using docker backend this would clear all of the docker instances

@dimakr
Copy link
Contributor

dimakr commented Nov 15, 2024

So when using docker backend this would clear all of the docker instances

Ok. I was not able to reproduce it, but will give another try.

@dimakr
Copy link
Contributor

dimakr commented Nov 15, 2024

@asias Could you please share details/command of how you was doing the problematic SCT run against docker backend (was it via hydra, ./sct.py, etc.)?

dimakr added a commit to dimakr/scylla-cluster-tests that referenced this issue Nov 18, 2024
There is no any filtering of docker instances, when killing containerized stress threads on
loader nodes during teardown of a test. In the case of docker backend this can result in
deleting all containers in the system.

The change fixes this by labeling stress thread related docker containers when they
are created; and deleting only the labeled containers during the teardown.

Fixes: scylladb#9027
dimakr added a commit to dimakr/scylla-cluster-tests that referenced this issue Nov 18, 2024
There is no any filtering of docker instances, when killing containerized stress threads on
loader nodes during teardown of a test. In the case of docker backend this can result in
deleting all containers in the system.

The change fixes this by labeling stress thread related docker containers when they
are created; and deleting only the labeled containers during the teardown.

Fixes: scylladb#9027
@soyacz soyacz closed this as completed in 87ffeb7 Nov 18, 2024
@asias
Copy link
Contributor Author

asias commented Nov 19, 2024

@asias Could you please share details/command of how you was doing the problematic SCT run against docker backend (was it via hydra, ./sct.py, etc.)?

e.g.,

hydra run-test performance_regression_test.PerformanceRegressionTest.test_latency_write_with_nemesis --backend docker --config test-cases/performance/perf-regression-latency-650gb-with-nemesis.yaml --config configurations/tablets_disabled.yaml --config configurations/disable_kms.yaml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working right
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants