Relation addresses

[Andrew Wilkins]

On Thu, Jun 19, 2014 at 5:21 AM, William Reade <william.reade at canonical.com>
wrote:

> 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.
>

If that's the case, why do we not just require charms to implement an
address-changed hook to update the relation setting then?
That way we don't break existing proxy charms, but other charms won't be
fixed until they implement that hook. We'd have to keep the initial
private-address value for backwards compatibility at least initially.

So how about this as an alternative proposal:
 - Add relation-address-changed, but don't add automatic updating of
private-address (after initial setting).
 - Continue to use "unit-get private-address". When we have networks, then
we can add "-r" and have it default to the current relation.

Pros:
 - Nothing to do on upgrade, no messy error-prone logic
 - No network specific bits added until they're added
 - No charms will be broken any more than they already are
Cons:
 - Existing non-proxy charms will need to be changed to take advantage of
the fix

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.
>

*In this case*, I don't think opting into a feature flag is any better than
opting into a charm hook.


> Cheers
> William
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140619/e0454fe9/attachment.html>