I thought this might be a dupe of: https://bugs.launchpad.net/juju-core/+bug/1245649 But I think that doesn't come into play until you have many 1000s of units of a single service (like 4k in my testing). I believe the internals of add-unit do each one-by-one, and from the above logs it looks like it doesn't reuse any of the information lookups. (It appears that it has to uniquely query the provider for all the information for each node, as well as do a full tools lookup.) I thought tools lookup was actually done in the Provisioner side, which should be asynchronous from add-unit doing its work. (I have seen that add-unit doesn't return as early as I would expect it to.) I don't know if it is just accidental interlocking (Provisioner is busy rewriting the same docs that AddUnit is trying to write as it tries to actually bring up new instances). All of those errors in the log appear to be on the Agent/Provisioner side, not directly in AddUnit. Those specific errors are actually just the InstancePoller trying to update IP addresses for various units, but there is no machine started for the unit yet, so it just returns an error for its IP address. Arguably it isn't actually an *error* yet. I'm guessing something is running "juju status" while the machines are coming up, and it is causing us to log messages about not actually having an instance for given machines yet. I filed https://bugs.launchpad.net/juju-core/+bug/1318148 that this shouldn't actually be considered an ERROR (it is expected that there will be a short period of time where a Unit doesn't have an IP address because its associated machine hasn't actually been brought up yet.) So there probably is still a performance bug that add-unit is doing a bit too much work before returning, but it isn't related to the above error messages (I believe). John =:-> On Fri, May 9, 2014 at 5:16 PM, James Page