Warn user when a command might corrupt dependent containers

[bjaglin]

When -a/--cascade-affected=none, commands such as lift -r, run -r, stop, pause might affect containers that directly or indirectly depend on them: side effects can be silent stale data in case of volumes dependency or verbose crashes in case of linked/net dependency. In that case, it would be interesting to check targeted containers as if --cascade-affected=all had been passed, and if it doesn't match the explicitly targeted one, show the missing containers in a warning, introducing the user to the flag as a way to safely run commands that alter the state of a container that others depend on.

[bjaglin]

Any opinion?

[michaelsauter]

Hmm, actually not too interested. It's something that Docker itself doesn't provide and I don't want Crane to be larger than necessary. Unless it becomes a pain point for a lot of people, I think I don't want this in Crane for now. Though in theory it sounds good :)

[bjaglin]

Thanks for your opinion! To be honnest, I don't think it's fair to compare the feature set of Docker with Crane, even though we are trying to keep mapping as tight as possible. Docker focuses on containers, one by one, while Crane is IMHO a low-level orchestrator, which should take the pain out of the user who do not necessarily know the side effects of restarting a container.

I know we had a similar discussion in #50, but ideally, I would like to see --cascade-affected have a more sensible default than none, since I get questions every week from one of our developers with a broken stack because he restarted/updated a container which other containers depended on. docker graph was a great improvement to give visibility on the consequences of such a restart. However Crane, with its current defaults, still falls short when it comes to provide feedback when dealing with complex dependency graphs (even though everything is in place). This PR was started as a tradeoff, to avoid changing the cascading default, while still utilizing the dependency handling within Crane to help the end user.

One other option would be to provide the ability to override CLI defaults via crane.yaml, simply by having a string or a list of strings defining a set of options always appended to the custom runtime options. If that makes sense to you, then I'd be happy to close this, and open a PR in the future. If not, I guess I'll just package crane with my own --cascade-affected default for now, since that's the only way I see to avoid getting recurring questions from people with a broken stack; let's see in the future if other people have the same needs as we do.

[mishak87]

Would it make sense to require -f|--force argument when trying to do destructive action that will affect other running or stopped containers not specified in arguments?
Without -f only warn user and ask for confirmation This action will might crash containers A, B and C, do you wish to continue [y/N].