<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 19, 2014 at 7:59 AM, 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 Wed, Jun 18, 2014 at 5:21 PM, William Reade <span dir="ltr"><<a href="mailto:william.reade@canonical.com" target="_blank">william.reade@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"><div class="gmail_extra"><div class="gmail_quote"><div>On Wed, Jun 18, 2014 at 7:05 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: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"><br><div><div>addresses are just keys in a unit relation data bag. relation-get is the cli tool to retrieve either self or related units databag key/values (ie for self's address in the rel $ relation-get $JUJU_UNIT_NAME private-address). unit-get is used to retrieve the current iaas properties of a unit.</div> </div></div></blockquote><div><br></div></div><div>Yes: unit-get retrieves iaas properties; and relation-get retrieves unit properties; but self's private-address is *not* put in self's relation data bag for the benefit of self; it's for the remote units that *react* to changes in that data bag. </div> </div></div></div></blockquote><div><br></div></div><div>Its not a write only bag and we don't constrain reads. Charms can retrieve their own relation properties when evaluating a remote relation change. address is simply a key in that bag. The benefit to self/local unit, and to all charm authors was the one boilerplate property that every single one of them needed to provide/relation-set was effectively handled by the framework. Afaics it also makes it easier for us to do some of the sdn relation binding because we provide that value else we'd be rewriting all extant charms to support it.</div> <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>Using `relation-get $JUJU_UNIT_NAME private-address` is Doing It Wrong: the canonical way to get that data is `unit-get private-address`, and the problem is not that we don't magically update the relation data bag: the problem is that we don't provide a means to know when the relation's data bag should be updated.</div> </div></div></div></blockquote><div><br></div></div><div>it sort of depends why your retrieving wrt to if its wrong, if a unit want's its own address then retrieving it directly from unit-get is clearly correct. if wants to reason about the address its advertising to related units, then retrieving from the relation is valid. Agreed re the issue being lack of updates. but adding -r to the unit-get seems to be more conflating of the relation data bags and iaas properties associated to a set of unit addresses. per the original network sketch i'd imagine in a multiple network and address world unit-get would grow facilities for retrieving list of networks and addresses. as for relation to network or route binding, it also seems its missing the notion of retrieving the named network on the rel.. ie either more framework relation properties.. or ideally this could get shuffled into relation-config or exposed more explicitly.</div> </div></div></div></blockquote><div><br></div><div>I think there's a misunderstanding here. "unit-get -r <relid> private-address" would be returnning an IaaS/machine address that relevant to the relation, and would have nothing to do with the relation settings. The idea being that each relation might have a different address, because you want to segregate network traffic.</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 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>Honestly, it's kinda bad that we prepopulate private-address *anyway*. It's helpful in the majority of cases, but it's straight-up wrong for proxy charms. </div> </div></div></div></blockquote> <div><br></div></div><div>its debatable, given that it would be simply boilerplate for the majority, its seems reasonable and its been easy for proxy charms to explicitly set what they want the actual value to be. Afaics the only real issue to-date has been juju isn't updating the property its populating.</div> <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>I don't want to take on the churn caused by reversing that decision; but equally I don't want to "fix" it with magical rewrites of the original magic writes.</div> </div></div></div></blockquote><div><br></div></div><div>to me its a question of ownership.. if the framework owned the value by providing it, then the framework is responsible for updating the value till such time as the charm takes ownership by writing a new one. </div> <div class=""> <div><br></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><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>my point regarding binding and addresses was more that we're forward thinking bug fixes by introducing a bunch of user facing stuff without having completely thought/designed or started implementation on the proposed solution that is the reason we're exposing additional things to users. instead i'd rather we just fix the bug, and actually implement the feature when we get around to implementing the feature. By the time we get around to implementing it (which for this cycle is against a single provider) we may have a different implementation and end-user exposed surface in mind. </div> </div></blockquote><div><br></div></div><div>That's not impossible; but I don't think it's a good reason to pick an approach at odds with our current best judgment of where we're heading.</div></div></div> </div></blockquote><div><br></div></div><div>but we're not heading there yet at best we're still doing plumbing afaics, and we're going to expose all this end user machinery which we'll have to support before we even started on the path and under the seeming aegis of providing a bug fix that could be addressed much more simply without exposing additional concepts and hooks to charm authors. ie. to me the analogy is the plumbing to the sink is stopped up, and instead of calling a plumber to clean the pipes, we're doing a renovation. yes we may want to do a renovation in the future, but that's no reason we shouldn't just fix the sink till we start it.</div> <div class=""> <div> <br></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><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">moreover the user facing (charm author) aspects of the changes as currently in the spec are going to be confusing, ie. relation hooks are always called for remote units, except for this one case which is special.</div> </div></blockquote><div><br></div></div><div>I don't agree that this one case is special; relation hooks are called in response to changes in a local unit's view of a relation, and those changes have hitherto *mostly* been about remote units. But I don't think it's fundamental -- and I'm not even sure it's very natural, I've corrected misconceptions about -joined referring to the local unit more than once.</div> </div></div></div></blockquote><div><br></div></div><div>addressed in other thread, and the misconceptions seem to support that understanding juju is hard and having a simple rule for what relation hooks apply to is a good thing. given the issues of lack of notifications and data ownership and that addresses are fundamentally a property of a unit that exists outside of a network scoped relation (or really any relation), why we're only informing units via a relation hook is strange.</div> <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><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">additionally i'd prefer we have a plan for maintaining backwards compatibilities with proxy charms that are already extant.</div> </div></blockquote><div><br></div></div><div>OK, let's talk about that :). Would a charm feature flag work for you? It's become pretty clear to me that we need them anyway; most charms could switch it on without issues, and proxy charms would be free to update on their own schedules.</div> </div></div></div></blockquote><div><br></div></div><div>i'm not sure feature flags should apply to correctness and bug fix issues.</div><div><br></div><div>-k</div><div><br></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><br></div><div>Cheers</div><span><font color="#888888"><div>William</div></font></span></div></div></div> </blockquote></div><br></div></div> <br>--<br> Juju-dev mailing list<br> <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br> <br></blockquote></div><br></div></div>