feedback about juju after using it for a few months

[Marco Ceppi]

On Thu Dec 18 2014 at 1:00:46 AM John Meinel <john at 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
> =:->
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20141218/33d1f332/attachment.html>