Why is unit id mandatory in config-changed context?

[Gustavo Niemeyer]

On Sat, Jun 1, 2013 at 3:20 PM, Andreas Hasenack <andreas at canonical.com> wrote:
> On Fri, May 31, 2013 at 8:42 PM, Gustavo Niemeyer <gustavo at niemeyer.net>
> wrote:
>>
>> On Fri, May 31, 2013 at 8:14 PM, Andreas Hasenack <andreas at canonical.com>
>> wrote:
>> > But aren't the key-value pairs that I set in the relation the same for
>> > all
>> > units?
>>
>> Yes, because it is associated with the local unit. It's similar to the
>> following scheme:
>>
>> relation R1:
>>     unit U1:
>>           setting S1=V1
>>           setting S2=V2
>>     unit U2:
>>           setting S1=V3
>>           setting S2=V4
>>           setting S3=V5
>>     unit U3:
>>           setting S1=V6
>>
>> If U1 does relation-set S1=V1, it sets its own S1 setting to V1. If it
>
>
> I think I have a basic misunderstanding of "scope". I didn't know the
> relation "variables" (let me call S1..S3 that) could be local and specific
> to a unit.

s/could be/are always/

> I thought all changes would eventually be propagated to all
> units, meaning these "variables" are "global" in the relation. Let's take
> your example above:
>
> U1 does relation-set S1=V1 in a hook relation, for example. When this hook
> finishes successfully, this change (S1=V1) is committed and the
> relation-changed hook is fired in U2 and U3, right?
>
> If U2 or U3 do relation-get S1 without specifying a unit, they will get V1 I
> suppose. But what if U2 does "relation-get -r R1 S1 U3"? Will it get V6 or
> V1? "Depends"?

It'll get S1 of U3, which is V6 until U3 changes it. Only U3 can ever change it.

Think about a set of N units exchanging host/port. How could the
setting ever be global?


gustavo @ http://niemeyer.net