Relation addresses

[William Reade]

On Wed, Jun 18, 2014 at 7:05 PM, Kapil Thangavelu <
kapil.thangavelu at canonical.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140618/045fe683/attachment.html>