normal charm to subordinate charm and now peer relation does not work

[Alex Kavanagh]

On Wed, Jan 25, 2017 at 1:08 PM, Tilman Baumann <
tilman.baumann at canonical.com> wrote:

>
>
> On 25.01.2017 13:06, Alex Kavanagh wrote:
> > Hi Tilman
> >
> > On Wed, Jan 25, 2017 at 11:43 AM, Tilman Baumann
> > <tilman.baumann at canonical.com <mailto:tilman.baumann at canonical.com>>
> wrote:
> >
> >     At this point I'm pretty sure that this is a bug or undocumented
> >     feature.
> >
> >
> >     The peer relation of a subordinate charm only has one conversation.
> >     Despite scope being 'global' in metadata.yaml and the RelationBase
> class
> >     being scope = scope.UNIT.
> >
> >
> > Shouldn't the metadata.yaml ALSO be 'unit' scope if you want individual
> > conversations without sharing the data between all the subordinate
> > units?  global would imply that all of the relations have the same
> > data?  The subordinate to principal relation will be unit (anyway), but
> > the peer is just like any other relation, except here it is between the
> > subordinate's on multiple machines.
>
> The naming is quite confusing here.
> There is a bug for that. https://bugs.launchpad.net/juju/+bug/1499900
> Container in this case means it 'converses' with the other services on
> the same unit. Global means, it can talk to everything.
>
> This should really be unified. The naming in reactive seems more
> intuitive. But in the end reactive is a layer on-top of charms, I guess
> reactive should have stayed with the established nomenclature here.
>


Ah, yes, of course, the difference between charms.reactive conversation
scopes and juju scopes.  I can feel some experimentation and a new blog
post coming on ...

Thanks
Alex.


-- 
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/20170125/860d8ced/attachment.html>