On Thu, Jun 19, 2014 at 7:59 AM, Kapil Thangavelu < [email protected]> wrote:
> > > > On Wed, Jun 18, 2014 at 5:21 PM, William Reade < > [email protected]> wrote: > >> On Wed, Jun 18, 2014 at 7:05 PM, Kapil Thangavelu < >> [email protected]> wrote: >> >>> >>> 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. >>> >> >> 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. >> > > 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. > > >> 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. >> > > 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. > 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. > 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. >> > > 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. > > >> 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. >> > > 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. > > >> 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. >>> >> >> 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. >> > > 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. > > >> >> 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. >>> >> >> 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. >> > > 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. > > >> >> additionally i'd prefer we have a plan for maintaining backwards >>> compatibilities with proxy charms that are already extant. >>> >> >> 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. >> > > i'm not sure feature flags should apply to correctness and bug fix issues. > > -k > > > >> >> Cheers >> William >> > > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
