William, let me introduce you to canonistack :) It has its own chaos monkey
that terminates instances when you least expect it :)
On Wed, Jun 19, 2013 at 8:41 AM, William Reade
<email address hidden>wrote:
> @ahasenack, juju expects that you'll use juju to manipulate the
> environment. Deliberately terminating an instance out-of-band is not
> supported behaviour at the moment; so I think the precise expression of
> the original bug is "invalid".
>
> @davidpbritton, just to be clear (with no implication that it's
> not-a-bug): I think that that use case *will* recover; it will just take
> a while to do so. I absolutely agree that it could and should be done
> faster when the unit agent's not running. If that's not the case, please
> post a status demonstrating the stuckness of deploy/destroy-service
> please (or just point me to the equivalent existing bug ofc)?
>
> Either way, I think this bug can be actionably characterized as "units
> of destroyed services are not destroyed if their agents are not
> running"; and fixing that will clearly improve the experience in both
> the described use cases. Sensible?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1190715
>
> Title:
> Unit in error, yet juju resolved claims it's fixed
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1190715/+subscriptions
>
William, let me introduce you to canonistack :) It has its own chaos monkey
that terminates instances when you least expect it :)
On Wed, Jun 19, 2013 at 8:41 AM, William Reade
<email address hidden>wrote:
> @ahasenack, juju expects that you'll use juju to manipulate the destroy- service /bugs.launchpad .net/bugs/ 1190715 /bugs.launchpad .net/juju- core/+bug/ 1190715/ +subscriptions
> environment. Deliberately terminating an instance out-of-band is not
> supported behaviour at the moment; so I think the precise expression of
> the original bug is "invalid".
>
> @davidpbritton, just to be clear (with no implication that it's
> not-a-bug): I think that that use case *will* recover; it will just take
> a while to do so. I absolutely agree that it could and should be done
> faster when the unit agent's not running. If that's not the case, please
> post a status demonstrating the stuckness of deploy/
> please (or just point me to the equivalent existing bug ofc)?
>
> Either way, I think this bug can be actionably characterized as "units
> of destroyed services are not destroyed if their agents are not
> running"; and fixing that will clearly improve the experience in both
> the described use cases. Sensible?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Unit in error, yet juju resolved claims it's fixed
>
> To manage notifications about this bug go to:
> https:/
>