Closed h4ck3rk3y closed 11 months ago
Currently the image deleting algorithm is to delete all non-dev images that are not being used. Did you have an APIC running? If not, it makes sense that it was deleted
This was a ease of implementation compromise, without having to deal with parsing semver, only customers that upgraded Kurtosis, ran an APIC, stopped the APIC, than ran clean -a would be affected, which seems a corner case
Yep, I didn't have an APIC running. I thought the algorithm was to delete previous versions, wasn't aware of this choice. My internet is alright so it doesn't affect me as much.
kurtosis clean -a
now deletes all images that I'm using, and every time I rerun kurtosis run, it has to download all images all over, this issue is super frustrating when you have slow internet connection:
kurtosis version 0.83.16
Container images used in this run:
postgres:alpine - remotely downloaded prom/prometheus:latest - remotely downloaded hyperledger/besu:develop - remotely downloaded redis:alpine - remotely downloaded grafana/grafana-enterprise:9.2.3 - remotely downloaded flashbots/mev-boost - remotely downloaded ethpandaops/dora-the-explorer:master - remotely downloaded ethpandaops/tx-fuzz:master - remotely downloaded ethpandaops/beacon-metrics-gazer:master - remotely downloaded ethpandaops/ethereum-genesis-generator:2.0.0-rc.6 - remotely downloaded ethereum/client-go:latest - remotely downloaded ethpandaops/execution-monitor:master - remotely downloaded nethermindeth/nethermind:cancun - remotely downloaded sigp/lighthouse - remotely downloaded flashbots/mev-flood - remotely downloaded python:3.11-alpine - remotely downloaded consensys/teku:latest - remotely downloaded ethpandaops/consensus-monitor:main - remotely downloaded flashbots/mev-boost-relay:0.28.0a1 - remotely downloaded flashbots/builder:1.13.2.dev1 - remotely downloaded
{
"participants": [
{
"el_client_type": "geth",
"cl_client_type": "teku",
"count": 3
},
{
"el_client_type": "nethermind",
"cl_client_type": "teku",
"el_client_image": "nethermindeth/nethermind:cancun"
},
{
"el_client_type": "besu",
"cl_client_type": "teku"
}
],
"network_params": {
"deneb_fork_epoch": 2,
"seconds_per_slot": 3
},
"global_client_log_level": "info",
"launch_additional_services": true,
"mev_type": "full",
"mev_params": {
"mev_relay_image": "flashbots/mev-boost-relay:0.28.0a1",
"mev_builder_image": "flashbots/builder:1.13.2.dev1"
}
}
My issue is caused by docker desktop running out of allocated disk space, and started to evict images. To resolve this, I increased the max allowed disk size (not ideal). I have created a new issue, which explains that there is some data creep happening in kurtosis which makes the Docker.raw file bigger after each run. #1459
@victorcolombo this is also surprising to me; IMO deleting images of the same version that Kurtosis is using is surprising behaviour to the user, and should never happen. It's also very problematic if the user is going to go offline.
also re. impl, we already do semver-parsing when we check if the CLI version matches the engine version; there's a Go library that does it.
Just to confirm @barnabasbusa, the images being evicted are not connected with the kurtosis clean -a
command, instead, there is some data creep that evicts images, that you created a different ticket to track it here https://github.com/kurtosis-tech/kurtosis/issues/1459 ?
The images weren't being cached for @barnabasbusa as he was running out of disk space. Closing this!
What's your CLI version?
0.83.16
Description & steps to reproduce
kurtosis clean -a
Desired behavior
This deletes 0.83.16 core/expander while it should keep that
What is the severity of this bug?
Papercut; this bug is frustrating, but I have a workaround.
What area of the product does this pertain to?
CLI: the Command Line Interface