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. 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. 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. 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. 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. 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. 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. Cheers William
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
