On Thu, Jun 8, 2017 at 2:38 PM, Cory Johns <[email protected]> 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 < > [email protected]> wrote: > >> >> >> On Wed, Jun 7, 2017 at 4:44 PM, Cory Johns <[email protected]> >> 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 < >>> [email protected]> 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 <[email protected]> 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 >>>>> [email protected] >>>>> >>>>> Lenovo.com >>>>> Twitter | Facebook | Instagram | Blogs | Forums >>>>> 9 >>>>> >>>>> >>>>> -- >>>>> Juju mailing list >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
