How to count relations?

Alex Kavanagh alex.kavanagh at canonical.com
Fri Jun 9 12:09:42 UTC 2017


On Thu, Jun 8, 2017 at 2:38 PM, Cory Johns <cory.johns at canonical.com> wrote:

> Alex,
>
> I should clarify, conv.scope should only be None if the class's scope is
> GLOBAL.  Otherwise, it should be the name of the service or unit.  If the
> scope is defined as SERVICE or UNIT and the conv.scope is None, it was a
> bug, yes (but let's work to get rid of the confusing idea of scopes and
> conversations anyway, instead).
>

Indeed.  The fact that we have juju scopes and charms.reactive scopes
*is* confusing,
although the conversations metaphor does work well with 1-to-1, but then
breaks down on 1-to-many.

>
> On Wed, Jun 7, 2017 at 12:30 PM, Alex Kavanagh <
> alex.kavanagh at canonical.com> wrote:
>
>>
>>
>> On Wed, Jun 7, 2017 at 4:44 PM, Cory Johns <cory.johns at canonical.com>
>> wrote:
>>
>>> Alex beat me to it, but here's a marginally more complete example:
>>> https://gist.github.com/johnsca/a91cb5897d92dfb6741ee1a09d82b39b
>>>
>>> The key points are:
>>>
>>> * The interface needs to be UNIT scoped (because you care about
>>> individual units)
>>> * The joined handler sets a state for each unit that joins
>>> * The @when('rel.connected') predicate in the charm layer matches all
>>> units that have had that state set, so the set of conversations in the
>>> interface layer includes those units, and only those units.  This is
>>> trivially all of the units in my example, but you could also set a
>>> different state in a -changed handler based on data sent by each remote
>>> unit, and the conversations would only include the units that had that
>>> specific state set when you matched that state using @when
>>>
>>> Alex: A conversation will always have a scope, so that list
>>> comprehension isn't necessary.
>>>
>>
>> Ah, interesting Cory.  It must have been a bug then; I ran into a
>> situation where scope was None and had to filter it out; maybe I can remove
>> that check from the interface I wrote (manila-plugin).
>>
>> Thanks!
>> Alex.
>>
>>
>>> On Wed, Jun 7, 2017 at 11:38 AM, Alex Kavanagh <
>>> alex.kavanagh at canonical.com> wrote:
>>>
>>>> Hi
>>>>
>>>> I'm assuming you are using charms.reactive; if not then look into
>>>> relation_ids command.
>>>>
>>>> In your interface, count the number of conversations that have a scope
>>>> set to something other than None.  scope shouldn't be None, but I've had
>>>> cases where it has been (it may have been a bug):
>>>>
>>>> So in the provider.py RelationBase derived class, something along the
>>>> lines of:
>>>>
>>>> num = len([c for c in self.conversations() if c.scope])
>>>>
>>>> in a method would be a relatively simple way of doing it.
>>>>
>>>> (There may be better ways of doing this!)
>>>>
>>>> Cheers
>>>> Alex.
>>>>
>>>> On Wed, Jun 7, 2017 at 4:22 PM, fengxia <fxia1 at lenovo.com> wrote:
>>>>
>>>>> Hi Juju,
>>>>>
>>>>> I'm building two charms and linking them with one relation, one charm
>>>>> ("A") will provide and the other ("B") will require.
>>>>>
>>>>> The deployment will have one "A" and three "B"s. How do I know all
>>>>> three Bs have joined? I'm thinking to use a counter in A's relation, then
>>>>> at relation-joined hook by B to add this counter. But set_remote() and
>>>>> set_local() didn't work. Not sure what's the right way to achieve this?
>>>>>
>>>>>
>>>>> --
>>>>> Feng xia
>>>>> Engineer
>>>>> Lenovo USA
>>>>>
>>>>> Phone: 5088011794
>>>>> fxia1 at lenovo.com
>>>>>
>>>>> Lenovo.com
>>>>> Twitter | Facebook | Instagram | Blogs | Forums
>>>>> 9
>>>>>
>>>>>
>>>>> --
>>>>> Juju mailing list
>>>>> Juju at lists.ubuntu.com
>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>> an/listinfo/juju
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alex Kavanagh - Software Engineer
>>>> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju at lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>> an/listinfo/juju
>>>>
>>>>
>>>
>>
>>
>> --
>> Alex Kavanagh - Software Engineer
>> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>>
>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170609/7e7d106d/attachment.html>


More information about the Juju mailing list