If start_nodes() fails, it doesn't clean up after itself.

Agree with moving to next if this is just handling Static IP exhaustion (which is unfortunate but not a showstopper).

Weirdly, I don't think start_nodes() (or stop_nodes()) can be properly atomic, because they handle multiple nodes, and one of those nodes could fail… etc. That said, *nowhere* is start_nodes() called with > 1 node, because reasons. So the callsites *are* atomic, which means that we could at least add explicit atomicity there and so have nice-ish rollbacks when things blow up for individual nodes.

We're now getting to the point where this can be a serious problem so I'm bumping the importance up. I'm already working on a fix, though, so that's mostly for the sake of making everyone else aware of what's going on.

After discussing this in the MAAS core team meeting, we came to the conclusion that since start_nodes() and stop_nodes() are never ever used with > 1 node, we should refactor them to handle *only* one node. That makes it much easier to be robust in the face of failure, because we're not having to revert parts of what's being done in those methods should something go wrong.

See also bug 1384926.

As I commented in bug 1384926, this bug and that one are not related:

 - This bug is about the fact that, if start_nodes() fails it can leave *static* IPs, hostmaps and DNS records lying around as shouldn't be.
 - Bug 1384926 is about the fact that when MAAS runs out or is close to running out of *dynamic* IPs, it doesn't warn anyone, and DHCP just starts failing silently.