A side effect of the reversion of #1967 is that weave launch* is no longer idempotent, which is undesirable.

no longer idempotent

Though based on #2186 the intended semantics of weave launch[-router] is "Use supplied peer list only", which is non-monotonic, thus making idempotence awkward and perhaps of little value to users.

It seems rather inconvenient that re-launching the router clears the persisted peer list. It makes all changes to the configuration, e.g. changing the log level, lossy. Upgrades per #2303 are just a special case of that.

Perhaps we need another variant (or flag) for weave launch. After all, we do have a variant of weave connect, i.e. weave connect --replace <peer-list>.

strawman A: Add weave launch --replace.

• when the weave container is restarted - we detect this via the sentinel file - the persisted peer list is used
• when the weave container is launched with --replace, the command line peer list is used
• when the weave container is launched without --replace, the union of the persisted peer list and the command line peer list is used

Downside: This is a change in the current behaviour of weave launch.

strawman B: make weave launch with any peers behave as "with --replace" above, and "without --replace" otherwise

Downside: This is still a change in current behaviour for the nil command line peer list case. It is also inconsistent with the weave connect --replace semantics (though we could change that to match).

strawman C: --add, i.e. the inverse of the --replace flag

Downside: Having a --replace flag for weave connect and the inverse flag for weave launch is inconsistent.

@rade I think I would prefer weave launch --resume which does not allow the specification of any peers.

CC @abuehrle doc change

LGTM apart from one comment.

I guess we should note in the description the breaking change that weave launch is no longer idempotent, for inclusion in release notes.