Missing --remove-orphans option

[chrissinclairedited]

I've got a kubetools.yml config file, where I've now changed a container from being dev: true to only being deployed in the production namespace & environment. This has left me with some orphaned containers. ktd reload spots this and suggests using the --remove-orphans flag to tidy them up:

ktd reload
--> Stopping containers
Stopping similarproductsindexerdev_local_1    ... done
Stopping similarproductsindexerdev_dynamodb_1 ... done
Stopping similarproductsindexerdev_s3_1       ... done
--> Containers stopped

--> "dev" environment state:
  - [STOPPED] dynamodb (dependency)
  - [STOPPED] s3 (dependency)
  - [RUNNING] cron
  - [STOPPED] local

Some containers are stopped; start them with: ktd start <container>

--> Building any out of date containers
--> Updating docker/Dockerfile-local

--> Starting containers
WARNING: Found orphan containers (similarproductsindexerdev_cron_1) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Recreating similarproductsindexerdev_dynamodb_1 ... done
WARNING: Found orphan containers (similarproductsindexerdev_cron_1) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Recreating similarproductsindexerdev_s3_1 ... done
WARNING: Found orphan containers (similarproductsindexerdev_cron_1) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Recreating similarproductsindexerdev_local_1 ... done
--> Dev environment up

--> Running upgrades
--> "dev" environment state:
  - [RUNNING] s3 (dependency) / 80/tcp -> http://dev.edtd.net:20019
  - [RUNNING] dynamodb (dependency) / 8000/tcp -> dev.edtd.net:26006
  - [RUNNING] cron
  - [RUNNING] local / 4040/tcp -> dev.edtd.net:19745

Use `ktd logs` to see what the containers are up to
Use `ktd attach <container>` to attach to a running container

However running that gives me a no such option error:

▶ ktd reload --remove-orphans
Usage: ktd reload [OPTIONS] [CONTAINERS]...
Try "ktd reload --help" for help.

Error: no such option: --remove-orphans

▶ ktd up --remove-orphans
Usage: ktd up [OPTIONS] [CONTAINERS]...
Try "ktd up --help" for help.

Error: no such option: --remove-orphans

▶ ktd start --remove-orphans
Usage: ktd start [OPTIONS] [CONTAINERS]...
Try "ktd start --help" for help.

Error: no such option: --remove-orphans

▶ ktd stop --remove-orphans
Usage: ktd stop [OPTIONS] [CONTAINERS]...
Try "ktd stop --help" for help.

Error: no such option: --remove-orphans

▶ ktd destroy --remove-orphans
Usage: ktd destroy [OPTIONS] [CONTAINERS]...
Try "ktd destroy --help" for help.

Error: no such option: --remove-orphans

[Fizzadar]

Ahhh! --remove-orphans is a docker-compose thing - was wondering why I couldn't find it anywhere. In this case we're simply forwarding the output from docker which isn't great.

We can certainly add it - does it make sense to add to every command (up/start/stop/restart/reload/destroy)?

[chrissinclairedited]

Hmmm what does docker-compose do? If it allows it on all commands I'd be inclined to replicate that behaviour.

[Fizzadar]

So ktd destroy will do this! https://github.com/EDITD/kubetools-client/blob/develop/kubetools_client/dev/container_util.py#L209

Agreed we should make it consistent with compose (also destroy vs down - though IMO compose's use of down is stupid/confusing).

[chrissinclairedited]

Ah that's interesting - just confusing that currently the docker-compose output asks for the --remove-orphans flag, but passing that to ktd destroy gives an error!

Agree that docker-compose down is a confusing command - destroy definitely better conveys what's going to happen (even if down is the opposite of up).

[Fizzadar]

@chrissinclairedited agreed!

Wonder if we can hook into the output of compose and remove/replace those lines. Maybe it's just easier to add --remove-orphans to up/destroy which map to the compose commands.

[chrissinclairedited]

Hmmm possibly - might be a bit awkward to filter out just those messages (I'm guessing you'd have to hook into the stdout / stderr stream from the compose process, and then be clever about stripping out just that text whilst respecting all the various control characters docker-compose uses).

TBH it might be easier to check if there are any orphans and if so present a ktd generated message explaining what's happening?