...
> > kill-controller will first try to kill via the API; if that fails, it does > the equivalent of "destroy-environment --force". I don't think there's much > else we can do, is there? > > We currently need one of two things: valid API connection details, or the > bootstrap configuration. In either case, it's going to break if the > configuration is invalid. In your case, you've got a missing > "controller-uuid" attribute, which was added as a mandatory attribute > between beta releases. In a non-beta release we would make sure that the > config changes aren't backwards incompatible. > > Cheers, > Andrew > But why do you actually need controller-uuid in order to kill the thing I just requested? There was a valid "uuid" available in controllers.yaml. Why not treat a failure to get "controller-uuid" the same as if we couldn't connect to the controller itself? My particular concern is that while I agree with "we need to be careful about compatibility", we're likely to make small errors here and there. And having something that really does clean up, even if the face of errors, seems better than something that a user is unable to resolve. As a *user* there is nothing they can do to get a "controller-uuid" into the system, so its the sort of thing that shouldn't block us cleaning up. Even if we gave a warning "encountered errors while killing controller, you may want to inspect your provider for blah". I can go around and manually cleanup machines/disk space, etc using tools I know about. As a user I don't know what is/isn't safe to cleanup Juju itself. John =:-> > > Thoughts? >> >> John >> =:-> >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
