<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 17, 2014 at 11:35 PM, Kapil Thangavelu <span dir="ltr"><<a href="mailto:kapil.thangavelu@canonical.com" target="_blank">kapil.thangavelu@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Tue, Jun 17, 2014 at 9:29 AM, John Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>...</div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr"><div>In a nutshell:</div><div> - There will be a new hook, relation-address-changed, and a new tool called address-get.</div></div></blockquote><div><br></div></div><div>This seems less than ideal, we already have standards ways of getting this data and being notified of its change. introducing non-orthogonal ways of doing the same lacks value afaics or at least any rationale in the document.</div>


</div></div></div></blockquote><div><br></div></div>So maybe the spec isn't very clear, but the idea is that the new hook is called on the unit when *its* private address might have changed, to give it a chance to respond. After which, "relation-changed" is called on all the associated units to let them know that the address they need to connect to has changed.<div>


<br></div><div>It would be possible to just roll relation-address-changed into config changed. </div></div></div></div></blockquote><div><br></div></div><div>or another unit level change hook (unit-address-changed), again the concerns are that we're changing the semantics of relation hooks to something fundamentally different for this one case (every other relation hook is called for a remote unit) and that we're doing potentially redundant event expansion and hook queuing as opposed to coalescing/executing the address set change directly at the unit scope level. </div>
<div class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>The reason it is called for each associated unit is because the network model means we can actually have different addresses (be connected on a different network) for different things related to me.</div>


<div><br></div><div>e.g. I have a postgres charm related to application on network A, but related to my-statistics-aggregator on network B. The address it needs to give to "application" should be different than the address given to "my-statistics-aggregator". And, I believe, the config in pg_hba.conf would actually be different.</div>

<div>
<div><br></div></div></div></div></div></blockquote><div><br></div></div><div>thanks, that scenario would be useful to have in the spec doc. As long as we're talking about unimplemented features guiding current bug fixes, realistically there's quite a lot of software that only knows how to listen on one address, so for network scoped relations to be more than advisory would also need juju to perform some form of nftables/iptables mgmt. Its feels a bit slippery that we'd be exposing the user to new concepts and features that are half-finished and not backwards-compatible for proxy charms as part of a imo critical bug fix. </div>
</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><div></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<div><br></div><div>the two perspectives of addresses for self vs related also seem to be a bit muddled. a relation hook is called in notification of a remote unit change, but now we're introducing one that behaves in the opposite manner of every other, and we're calling it redundantly for every relation instead of once for the unit?</div>


<div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> - The hook will be called when the relation's address has changed, and the tool can be called to obtain the address. If the hook is not implemented, the private-address setting will be updated. Otherwise it is down to you to decide how you want to react to address changs (e.g. for proxy charms, probably just don't do anything.)</div>



</div></blockquote><div><br></div></div><div>perhaps there is a  misunderstanding of proxies, but things that set their own address have taken responsibility for it. ie juju only updates private address if it provided it, else its the charms responsibility.</div>



<div> </div><div>fwiw, i think this could use some additional discussion.</div><div><br></div></div></div></div></blockquote><div><br></div></div><div>So one of the reasons is that it takes some double handling of values to know if the existing value was the one that was what we last set it. And there is the possibility that it has changed 2 times, and it was the value we set it to, but that was the address before this one and we just haven't gotten to update it.</div>


<div>There was a proposal that we could effectively have 2 fields "this is the private address you are sharing, which might be empty" and "this is the private address we set" which is where we put our data. And we return the second value if the first is still nil. Or we set it twice, and we only set the first one if it matches what was in the second one, etc.</div>


<div>All these things are possible, but in the discussions we had it seemed simpler to not have to track extra data for marginal benefit. Things which are proxy charms know that they are, and they found the right address to give in the past, and they simply do the same thing again when told that we want to change their address.</div>

</div></div></div></blockquote><div><br></div></div><div>there's lots of other implementation complexity in juju that we don't leak, we just try to present a simple interface to it. we'd be breaking existing proxy charms if we update the values out from the changed values. The simple basis of update being you touched you own it and if you didn't it updates, is simple, explicit, and backwards compatible imo. </div>

<div><br></div><div>There's also the question of why the other new hook (relation-created) is needed or how it relates to this functionality, or why the existing unit-get private-address needs to be supplemented by address-get.</div>
</div></div></div></blockquote><div><br></div><div>relation-created is not strictly required for this work, it just came up during discussions as a way for charms to do once-off setup of relation settings. I probably should have left it out of the doc.</div>
<div><br></div><div>I suppose "unit-get private-address" could be extended to take a relation ID.</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 class="gmail_extra"><div class="gmail_quote"><div> </div><div>chers,</div><div><br></div><div>Kapil</div><div><br></div></div></div></div>
</blockquote></div><br></div></div>