Relation addresses

[Kapil Thangavelu]

On Wed, Jun 18, 2014 at 5:21 PM, 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.
>

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.


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140618/a2897663/attachment.html>