Relation addresses

[Andrew Wilkins]

On Thu, Jun 19, 2014 at 7:59 AM, Kapil Thangavelu <
kapil.thangavelu at canonical.com> wrote:

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

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
> 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/5cb912da/attachment-0001.html>