deploy can fail partially

[Roger Peppe]

Here's a transcript:

% juju deploy juju-gui --force-machine 0
error: cannot assign unit "juju-gui/0" to machine 0: machine "0" cannot host units
% juju deploy juju-gui
error: cannot add service "juju-gui": service already exists
% juju status
machines:
  "0":
    series: precise
    instance-id: i-7cc72112
    dns-name: ec2-23-23-14-154.compute-1.amazonaws.com
    agent-version: 1.9.14
    agent-state: started
services:
  juju-gui:
    charm: cs:precise/juju-gui-46
    exposed: false
    units:
      juju-gui/0:
        agent-state: pending
% juju destroy-unit juju-gui/0
% juju add-unit juju-gui
%

The deploy failed to assign the new unit to the desired machine,
but left it around after failing. It seems like we should clean
up after failure - in fact should the service even be left created
in this case?

[William Reade (fwereade)]

I don't think we should clean up after failure in this specific case -- that's just automating the `destroy-unit` paperwork the user can themselves do to resolve the situation. The right answer, I believe, is to create and assign units in a single transaction and thereby completely eliminate the absurd gap in which they exist but no other entity in the system is responsible for their lifecycle.

Deploy is still itself fundamentally several actions rolled into one: upload-charm, add-charm-to-state, add-service-to-state, set-service-config, add-unit, assign-unit, ... -- and the closer we can come to unifying them the better [0], but it is at least currently possible to detect, and to resolve, a failure at any such stage, so I'm generally opposed to layering on rollbacky workarounds when we could be fixing the transactions.

However, a generalised deploy transaction will become unfeasible at some number of units; doing this all perfectly is likely to involve additional infrastructure, and may be time consuming.

[0] (I'd like to see the last ones compressed into add-service-with-config-and-n-units, really, but I think charms should stay separate).

[William Reade (fwereade)]

split out lp:1174104 which originally exposed the issue and is higher priority

[William Reade (fwereade)]

Dropping to low, because such problems are (1) rare and (2) always detectable and fixable as described in #1.

[Anastasia (anastasia-macmood)]

A lot has changed since this bug was originally filed.

If you can reproduce with Juju 2, please file a bug against "juju" with reproducible scenario and newer logs.