On Thu Dec 18 2014 at 1:00:46 AM John Meinel <j...@arbash-meinel.com> wrote:
> ... > > >> 9. If you want to cancel a deployment that just started you need to keep >>>>> running remove-service forever. Juju will simply ignore you if it's still >>>>> running some special bits of the charm or if you have previously asked it >>>>> to cancel the deployment during its setting up. No errors, no other >>>>> messages are printed. You need to actually open its log to see that it's >>>>> still stuck in a long apt-get installation and you have to wait until the >>>>> right moment to remove-service again. And if your connection is slow, that >>>>> takes time, you'll have to babysit Juju here because it doesn't really >>>>> control its services as I imagined. Somehow apt-get gets what it wants :-) >>>>> >>>> >>>> You can now force-kill a machine. So you can run `juju destroy-service >>>> $service` then `juju terminate-machine --force #machine_number`. Just make >>>> sure that nothing else exists on that machine! I'll raise an issue for >>>> having a way to add a --force flag to destroying a service so you can just >>>> say "kill this with fire, now plz" >>>> >>> >>> I understand that, but I discovered it's way faster and less typing if I >>> simply destroy-environment and bootstrap it again. If you need to force >>> kill something every time you need to kill it, then perhaps somethings is >>> wrong? >>> >> >> I agree, something is wrong with the UX here. We need to (and would love >> your feedback) figure out what should happen here. The idea is, if a >> service experiences a hook failure, all events are halted, including the >> destroy event. So the service is marked as dying but it can't die until the >> error is resolved. There are cases, where during unit termination, that you >> may wish to inspect an error. I think adding a `--force` flag to destroy >> service would satisfy what you've outlined, where --force will ignore hook >> errors during the destruction of a service. >> >> Thanks, >> Marco Ceppi >> >>> > IIRC, the reason we support "juju destroy-machine --force" but not "juju > destroy-unit --force" is because in the former case, because the machine is > no-more Juju has ensured that cleanup of resources really has happened. > (There are no more machines running that have software running you don't > want.) > The difficulty with "juju destroy-unit --force" is that it doesn't > necessarily kill the machine, and thus an unclean teardown could easily > leave the original services running (consider collocated deployments). > "juju destroy-service --force" falls into a similar issue, only a bit more > so since some units may be on shared machines and some may be all by > themselves. > Right, and I agree. This isn't the best thing for --force at a service or unit level. What I would like to see instead is the scenario "I just typed deploy on this service and I have three units and I don't want it anymore or this is a mistake" in which case destroy-service --force would execute the destruction of the service and set juju into a state where when a hook errors (or if it's in an error state) auto-resolve that and continue with service destruction. Then the machine can just be reaped with the upcoming machine reaper stuff and everything moves forward. That said, I feel like we're doing a little throwing the baby out with the > bathwater. If you are in a situation where there is just one unit on each > machine, then destroy-unit --force could be equivalent to destroy-machine > --force, and that could chain up into destroy-service --force (if all units > of service are the only thing on their machines, then tear them all down > ignoring errors and stop the machines). > > John > =:-> >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju