<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 24, 2015 at 12:55 PM Cheryl Jennings <<a href="mailto:cheryl.jennings@canonical.com">cheryl.jennings@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'll be tracking these kind of feature requests here: <a href="https://github.com/juju/juju/wiki/Feature-Requests" target="_blank">https://github.com/juju/juju/wiki/Feature-Requests</a><div><br></div><div>There's not much there yet, but we'll be filling it out as we go through the other various requests we've gotten.</div></div></blockquote><div><br></div><div>Comment from the sidelines: we have something similar in storage now, with "storage-detaching" hook. This runs before storage is detached, so that charms can stop using the storage before it's ripped out beneath them.<br></div><div><br></div><div>With that in mind, can we please call this "-relation-departing"?</div><div><br></div><div>Cheers,</div><div>Andrew</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks!</div></div><div dir="ltr"><div>-Cheryl</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 23, 2015 at 6:13 PM, Rick Harding <span dir="ltr"><<a href="mailto:rick.harding@canonical.com" target="_blank">rick.harding@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Thank you Cheryl!</p><div><div>
<br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 23, 2015, 6:33 PM Cheryl Jennings <<a href="mailto:cheryl.jennings@canonical.com" target="_blank">cheryl.jennings@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">This is already on my list. I'm still figuring out a good way to organize / record these in a publicly viewable place.</p>
<p dir="ltr">I'll send out a link once I get something together. (Hopefully tonight!)</p>
<p dir="ltr">Thanks!</p><p dir="ltr"><br>
-Cheryl</p>
<div class="gmail_quote">On Nov 23, 2015 5:20 PM, "Rick Harding" <<a href="mailto:rick.harding@canonical.com" target="_blank">rick.harding@canonical.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the feedback. I think this is something we should try to make some time for. I've copied Alexis and we'll see what can be done with the team. <div><br></div><div>Alexis, can you put this on the list of things to investigate for future roadmap?</div><div><br></div><div>Thanks<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 10, 2015 at 8:22 AM Mario Splivalo <<a href="mailto:mario.splivalo@canonical.com" target="_blank">mario.splivalo@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/12/2015 07:41 PM, Jorge Niedbalski wrote:<br>
>> While typing up <a href="https://bugs.launchpad.net/juju-core/+bug/1417874" rel="noreferrer" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1417874</a> I<br>
>> realized that your proposed solution of a pre-departure hook is the<br>
>> only one that can work. Once -departed hooks start firing both the<br>
>> doomed unit and the leader have already lost the access needed to<br>
>> decommission the departing node.<br>
><br>
> I have been struggling the last hours with the same exact issue trying<br>
> to add replication to memcached.<br>
><br>
> The problem is that there is no a point on which i can identify<br>
> what's the exact departing unit?<br>
><br>
> And this leads to manual operator intervention, which is _highly_ non<br>
> desirable for a juju deployed environment.<br>
><br>
> +1 for having this feature implemented.<br>
<br>
Hola!<br>
<br>
I'm bumping this thread to get some chatter going on - we hit a similar<br>
issue with percona-cluster charm, which is reported in this bug:<br>
<br>
<a href="https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1514472" rel="noreferrer" target="_blank">https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1514472</a><br>
<br>
The issue is somewhat similar as to those with mongodb - when unit is<br>
leaving relation (issued by 'juju remove-unit'), charm should first shut<br>
down percona server on the departing unit. Failing to do results in<br>
'lost quorum' situation where remaining node thinks that network has<br>
partitioned. Unfortunately there is now way for a relation's -departed<br>
hook to know if it's executing on departing unit or on the other one so<br>
it can't know weather or not to stop percona server. Implementing a<br>
-about-to-depart hook would solve this issue.<br>
<br>
Mario<br>
<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div></div></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div></div>