Destroying a service that is in trouble

[Kapil Thangavelu]

The destroy-service command didn't need to be reissued (the lifecycle:
'dying' shows it was recorded). You could have unconditionally resolved
with out logging into the unit by omitting the '--retry' flag when running
juju resolved

There's an outstanding bug against core to allow a force option to avoid
the need for the manual resolving aspects here.

cheers,

Kapil


On Thu, Jun 6, 2013 at 2:12 PM, Andreas Hasenack <andreas at canonical.com>wrote:

> On Thu, Jun 6, 2013 at 3:05 PM, Andreas Hasenack <andreas at canonical.com>wrote:
>
>> I don't care about that relation error. In fact, I was on my way to
>> destroying this service and I was trying to be nice and did a "juju
>> relation-remove" first, but that failed due to a bug in the postgresql
>> charm. In fact, I deployed the wrong charm, as I don't wanted the one from
>> the store, that's why I'm trying to destroy this service.
>>
>> I don't want or need to resolve that state, I want the unit and the
>> service gone so I can deploy again., the right postgresql charm this time.
>> destroy-unit, remove-unit, destroy-service and terminate-machine don't do a
>> thing.
>>
>>
> Ok, so I had to ssh in and fix it. The easiest fix was:
>
>     sudo cp /bin/true
> /var/lib/juju/agents/unit-postgresql-0/charm/hooks/db-admin-relation-broken
>
> Then I came back, ran juju resolved --retry postgresql/0
>
> And then destroy-service and terminate-machine worked.
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130606/ff0ad124/attachment.html>