The --no-wait option is really useful, especially in large models and when an application has several units. But I hate the idea of stablising a double negative.
Rationale
Hard to communicate, esp. under stress
I expect that instances where --force is required, something may have gone wrong. If this happens, it’s going to be a stressful situation. Double negatives are terrible for communication, especially in teams with members who are not native English speakers. --asap is short, reflects the option’s role, easy to communicate and easy to type.
Wait for what?
The natural question to ask is, when encountering a --no-wait options is “why would Juju intentionally wait?”. --asap doesn’t fix this directly, but is less of a leading statement in my opinion.
Juju uses the --wait argument in places. Having --no-wait provides a symmetry to that. Non English speakers aren’t necessarily going to be familiar with what the ASAP acronym means. In general we try to keep the number of distinct keywords used for Juju commands and options to as small a set as possible, and this also fits in with that.
@wallyworld the issue that (I think) I see here is that Juju’s normal --wait actually has a different semantic meaning here - generally, --wait will mean “Wait until $thing is done and show me the result” where here, I think the --no-wait will mean something more akin to “do $thing and don’t wait for other things to finish.”
While I agree that having less keywords is something to strive for, I don’t think that it’s worth chasing that idea to the point of having multiple meanings stacked on a single keyword (wait). Maybe --asap is a bad idea for a new keyword in this context as it may be less useful for non native English speakers, but maybe something like --fast, --unblocking, or something else would be a more useful new flag.
The semantic though for juju remove-xxx --no-wait really is “remove thing X without waiting for the agent or other collaborating components to gracefully terminate”. It is not really “fast” (it will always happen as fast as possible), nor “unblocking”, since the remove command does return immediately and the user doesn’t see any blocking behaviour. Naming things is hard.
Right, that’s kind of my point: juju run-action $x --wait is semantically very different from juju remove-xxx --no-wait in that the first actually waits to return output to a user, while the second forcefully terminates things, rather than waiting for graceful cleanup.
skip-cleanup I think sounds ok as it captures what is happening.
It would mean Juju 2.6.3 would differ from 2.6.2 but I suspect no one would be using --no-wait yet in reality.
Note that either of these is just an alias for setting timeout=0 under the hood. Since it’s almost impossible to predict what a suitable timeout should be in any given scenario, it made little sense to expose that knob.
