Re: normal charm to subordinate charm and now peer relation does not work
Hi Tilman
That's very useful. Based on your work I'm definitely going to explore the
interactions of all of these scopes!
Cheers
Alex.
On Fri, Jan 27, 2017 at 12:16 PM, Tilman Baumann <
tilman.baum...@canonical.com> wrote:
> OMG, I went way deep down the rabbit hole.
>
> I had to find charms.reactive.join() to find what the difference of the
> scopes really means.
>
> This kept me busy and questioning my sanity for two days:
> $ git diff
> diff --git a/peers.py b/peers.py
> index 976c0ad..93cda29 100644
> --- a/peers.py
> +++ b/peers.py
> @@ -12,7 +12,7 @@ from charms.reactive import scopes
>
>
> class PeerDiscovery(RelationBase):
> -scope = scopes.UNIT
> +scope = scopes.SERVICE
>
> class states(StateList):
> connected = State('{relation_name}.connected')
>
> Sometimes software engineering feels just like a farce. :)
>
>
> Cheers guys, I hope you where entertained.
> Tilman
>
> On 25.01.2017 16:54, Tilman Baumann wrote:
> > On 25.01.2017 15:49, Tilman Baumann wrote:
> >> On 25.01.2017 14:24, Tilman Baumann wrote:
> >>> On 25.01.2017 13:16, Stuart Bishop wrote:
> On 25 January 2017 at 18:43, Tilman Baumann
> >>>
> I don't know why your peer relation (with global scope) starts
> misbehaving after you add the container scoped juju-info relation to
> turn your charm into a subordinate. It might be helpful to inspect the
> peer relation with the hook environment tools to try to narrow down if
> the problem is with Juju, charms.reactive, or something else. Using
> debug-hooks, or 'juju run --unit foo/0 "relation-ids ssh-peers"' and
> 'juju run --unit foo/0 "relation-list -r ssh-peers:64"' if you haven't
> done this before.
> >>>
> >>> Thanks. That was the breakthrough hint.
> >>> [...]
> >>> It is either reactive or my charm code.
> >>
> >> Reactive.
> >>
> >> Shortened version of my debug interface code:
> >>
> >> @hook('{peers:peer-discovery}-relation-{joined,changed}')
> >> def changed(self):
> >> for conv in self.conversations():
> >> log("JujuInfoClient Conversation.serialize():
> >> {}".format(conv.__class__.serialize(conv)))
> >>
> >> I get:
> >> Conversation.serialize(): {'scope': 'iptables-peer-ssh/102',
> >> 'namespace': 'ssh-peers:105', 'units': ['iptables-peer-ssh/102']}
> >>
> >> I have to go deeper down the rabbit hole. But somehow the Conversations
> >> get initialised with bullshit.
> >>
> >> This would be a example of a correctly initialised conversion.
> >> {'scope': 'global', 'units': ['dokuwiki/25'], 'namespace':
> 'host-system'}
> >>
> >> I will go bare-metal with charmhelpers and see what I get there...
> >>
> >
> > charmhelpers.core.hookenv tools seem to perform as expected
> >
> > units = related_units()
> > for unit in units:
> > relation_get('private-address', unit)
> >
> > I will bodge up a workaround with that now in order to be able to
> > deploy. But surely there is something wrong in the way RelationBase gets
> > initialised...
> >
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
--
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
OMG, I went way deep down the rabbit hole.
I had to find charms.reactive.join() to find what the difference of the
scopes really means.
This kept me busy and questioning my sanity for two days:
$ git diff
diff --git a/peers.py b/peers.py
index 976c0ad..93cda29 100644
--- a/peers.py
+++ b/peers.py
@@ -12,7 +12,7 @@ from charms.reactive import scopes
class PeerDiscovery(RelationBase):
-scope = scopes.UNIT
+scope = scopes.SERVICE
class states(StateList):
connected = State('{relation_name}.connected')
Sometimes software engineering feels just like a farce. :)
Cheers guys, I hope you where entertained.
Tilman
On 25.01.2017 16:54, Tilman Baumann wrote:
> On 25.01.2017 15:49, Tilman Baumann wrote:
>> On 25.01.2017 14:24, Tilman Baumann wrote:
>>> On 25.01.2017 13:16, Stuart Bishop wrote:
On 25 January 2017 at 18:43, Tilman Baumann
>>>
I don't know why your peer relation (with global scope) starts
misbehaving after you add the container scoped juju-info relation to
turn your charm into a subordinate. It might be helpful to inspect the
peer relation with the hook environment tools to try to narrow down if
the problem is with Juju, charms.reactive, or something else. Using
debug-hooks, or 'juju run --unit foo/0 "relation-ids ssh-peers"' and
'juju run --unit foo/0 "relation-list -r ssh-peers:64"' if you haven't
done this before.
>>>
>>> Thanks. That was the breakthrough hint.
>>> [...]
>>> It is either reactive or my charm code.
>>
>> Reactive.
>>
>> Shortened version of my debug interface code:
>>
>> @hook('{peers:peer-discovery}-relation-{joined,changed}')
>> def changed(self):
>> for conv in self.conversations():
>> log("JujuInfoClient Conversation.serialize():
>> {}".format(conv.__class__.serialize(conv)))
>>
>> I get:
>> Conversation.serialize(): {'scope': 'iptables-peer-ssh/102',
>> 'namespace': 'ssh-peers:105', 'units': ['iptables-peer-ssh/102']}
>>
>> I have to go deeper down the rabbit hole. But somehow the Conversations
>> get initialised with bullshit.
>>
>> This would be a example of a correctly initialised conversion.
>> {'scope': 'global', 'units': ['dokuwiki/25'], 'namespace': 'host-system'}
>>
>> I will go bare-metal with charmhelpers and see what I get there...
>>
>
> charmhelpers.core.hookenv tools seem to perform as expected
>
> units = related_units()
> for unit in units:
> relation_get('private-address', unit)
>
> I will bodge up a workaround with that now in order to be able to
> deploy. But surely there is something wrong in the way RelationBase gets
> initialised...
>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
On 25.01.2017 15:49, Tilman Baumann wrote:
> On 25.01.2017 14:24, Tilman Baumann wrote:
>> On 25.01.2017 13:16, Stuart Bishop wrote:
>>> On 25 January 2017 at 18:43, Tilman Baumann
>>
>>> I don't know why your peer relation (with global scope) starts
>>> misbehaving after you add the container scoped juju-info relation to
>>> turn your charm into a subordinate. It might be helpful to inspect the
>>> peer relation with the hook environment tools to try to narrow down if
>>> the problem is with Juju, charms.reactive, or something else. Using
>>> debug-hooks, or 'juju run --unit foo/0 "relation-ids ssh-peers"' and
>>> 'juju run --unit foo/0 "relation-list -r ssh-peers:64"' if you haven't
>>> done this before.
>>
>> Thanks. That was the breakthrough hint.
>> [...]
>> It is either reactive or my charm code.
>
> Reactive.
>
> Shortened version of my debug interface code:
>
> @hook('{peers:peer-discovery}-relation-{joined,changed}')
> def changed(self):
> for conv in self.conversations():
> log("JujuInfoClient Conversation.serialize():
> {}".format(conv.__class__.serialize(conv)))
>
> I get:
> Conversation.serialize(): {'scope': 'iptables-peer-ssh/102',
> 'namespace': 'ssh-peers:105', 'units': ['iptables-peer-ssh/102']}
>
> I have to go deeper down the rabbit hole. But somehow the Conversations
> get initialised with bullshit.
>
> This would be a example of a correctly initialised conversion.
> {'scope': 'global', 'units': ['dokuwiki/25'], 'namespace': 'host-system'}
>
> I will go bare-metal with charmhelpers and see what I get there...
>
charmhelpers.core.hookenv tools seem to perform as expected
units = related_units()
for unit in units:
relation_get('private-address', unit)
I will bodge up a workaround with that now in order to be able to
deploy. But surely there is something wrong in the way RelationBase gets
initialised...
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
On 25.01.2017 14:24, Tilman Baumann wrote:
> On 25.01.2017 13:16, Stuart Bishop wrote:
>> On 25 January 2017 at 18:43, Tilman Baumann
>
>> I don't know why your peer relation (with global scope) starts
>> misbehaving after you add the container scoped juju-info relation to
>> turn your charm into a subordinate. It might be helpful to inspect the
>> peer relation with the hook environment tools to try to narrow down if
>> the problem is with Juju, charms.reactive, or something else. Using
>> debug-hooks, or 'juju run --unit foo/0 "relation-ids ssh-peers"' and
>> 'juju run --unit foo/0 "relation-list -r ssh-peers:64"' if you haven't
>> done this before.
>
> Thanks. That was the breakthrough hint.
> [...]
> It is either reactive or my charm code.
Reactive.
Shortened version of my debug interface code:
@hook('{peers:peer-discovery}-relation-{joined,changed}')
def changed(self):
for conv in self.conversations():
log("JujuInfoClient Conversation.serialize():
{}".format(conv.__class__.serialize(conv)))
I get:
Conversation.serialize(): {'scope': 'iptables-peer-ssh/102',
'namespace': 'ssh-peers:105', 'units': ['iptables-peer-ssh/102']}
I have to go deeper down the rabbit hole. But somehow the Conversations
get initialised with bullshit.
This would be a example of a correctly initialised conversion.
{'scope': 'global', 'units': ['dokuwiki/25'], 'namespace': 'host-system'}
I will go bare-metal with charmhelpers and see what I get there...
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
This is one of the areas we're going to improve with Reactive 2.0, where the relation scope will be obsoleted as it's confusing and doesn't add much value to the overall framework. Updates and plans regarding that will be available soon! Marco On Wed, Jan 25, 2017 at 8:40 AM Alex Kavanagh wrote: > On Wed, Jan 25, 2017 at 1:08 PM, Tilman Baumann < > tilman.baum...@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 > > mailto:tilman.baum...@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 > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
On Wed, Jan 25, 2017 at 1:08 PM, Tilman Baumann < tilman.baum...@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 > > mailto:tilman.baum...@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 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
On 25.01.2017 13:16, Stuart Bishop wrote: > On 25 January 2017 at 18:43, Tilman Baumann > I don't know why your peer relation (with global scope) starts > misbehaving after you add the container scoped juju-info relation to > turn your charm into a subordinate. It might be helpful to inspect the > peer relation with the hook environment tools to try to narrow down if > the problem is with Juju, charms.reactive, or something else. Using > debug-hooks, or 'juju run --unit foo/0 "relation-ids ssh-peers"' and > 'juju run --unit foo/0 "relation-list -r ssh-peers:64"' if you haven't > done this before. Thanks. That was the breakthrough hint. $ juju run --unit iptables-peer-ssh/97 "relation-list -r ssh-peers:103" iptables-peer-ssh/95 iptables-peer-ssh/98 iptables-peer-ssh/99 $ juju run --unit iptables-peer-ssh/97 "relation-get -r ssh-peers:103 private-address iptables-peer-ssh/95" 172.16.254.217 $ juju run --unit iptables-peer-ssh/97 "relation-get -r ssh-peers:103 private-address iptables-peer-ssh/98" 172.16.254.232 $ juju run --unit iptables-peer-ssh/97 "relation-get -r ssh-peers:103 private-address iptables-peer-ssh/99" 172.16.254.43 So clearly, the problem is not juju. I can see all relations. It is either reactive or my charm code. > One thing to remember is that units join the peer relation one at a > time. So in your peer relation-joined hook, you will only see a single > unit. Then a relation-changed, again with a single unit. And maybe a few > more times with a single unit. Eventually the rest of the units will > join, each time triggering relation-changed one or more times. Maybe > your problem is just that you are looking too soon :) Hm, perhaps that is the case. Though I should get the joined event multiple times until the last unit has joined. But I think I can keep working on this now, once the problem is isolated a little more. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
On 25.01.2017 13:06, Alex Kavanagh wrote: > Hi Tilman > > On Wed, Jan 25, 2017 at 11:43 AM, Tilman Baumann > mailto:tilman.baum...@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. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
On 25 January 2017 at 18:43, Tilman Baumann 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. > Relation scopes declared in metadata.yaml have no relation to conversation scopes, which are a charms.reactive concept. A relation scope of 'container' means that the relation data is not visible to other units. The subordinate unit can see the host unit's relation data and vice versa. Neither can see the relation data on the relation from their peer units. It looks like a relation with just two end points, rather than the normal case of one end point for each unit in the two related services. It gets very, very confusing when one end declares container scoped and the other end global, so don't do that :) I don't know why your peer relation (with global scope) starts misbehaving after you add the container scoped juju-info relation to turn your charm into a subordinate. It might be helpful to inspect the peer relation with the hook environment tools to try to narrow down if the problem is with Juju, charms.reactive, or something else. Using debug-hooks, or 'juju run --unit foo/0 "relation-ids ssh-peers"' and 'juju run --unit foo/0 "relation-list -r ssh-peers:64"' if you haven't done this before. One thing to remember is that units join the peer relation one at a time. So in your peer relation-joined hook, you will only see a single unit. Then a relation-changed, again with a single unit. And maybe a few more times with a single unit. Eventually the rest of the units will join, each time triggering relation-changed one or more times. Maybe your problem is just that you are looking too soon :) > > Either I'm wrong to expect this to work and subordinates are only > supposed to have container scopes. Then it is a dokufix and should be > caugt by charm proof. > Its fine as far as Juju in concerned. The cs:ntp subordinate has both a global scoped peer relation and a container scoped juju-info relation ( https://jujucharms.com/ntp). I don't know about the charms.reactive conversation or relation object, but I can't see why its behaviour would change once you add the container scoped juju-info relation and think it more likely that the problem lies elsewhere. -- Stuart Bishop -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
Hi Tilman On Wed, Jan 25, 2017 at 11:43 AM, Tilman Baumann < tilman.baum...@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. Cheers Alex. > Either I'm wrong to expect this to work and subordinates are only > supposed to have container scopes. Then it is a dokufix and should be > caugt by charm proof. > > Or, it is a bug. I could not find the point in the code which could be > wrong here. If anyone points me to the right place I would not mind > working on a fix. In go or python. > > Thanks > Tilman > > > PS: File as bug in LP? > > > On 25.01.2017 11:00, Tilman Baumann wrote: > > On 24.01.2017 16:56, Alex Kavanagh wrote: > >> Hi Tilman > >> > >> (I'm not an expert here, but was staring at the docs) > >> > >> I suspect that your peers relationship should be unit if each peer needs > >> to have it's own conversation? Otherwise, with a global scope, every > >> peer will overwrite the other's information? At least I'm wondering if > >> that what the scopes mean: see > >> here: https://jujucharms.com/docs/2.0/developer-layers-interfaces > >> > >> If that's completely wrong, then a) sorry for the noise, and b) do tell, > >> as it will help me in my understanding of juju scopes. > > > > No I think this must generally be the direction I need to think towards. > > Any thought impulse in that direction can unlock the knot in my head. :) > > > > Thing is, my interface class is scope UNIT already. (GLOBAL and SERVICE > > definitely would be wrong I think) > > > > What hasn't really connected in my brain is how this relates to the > > scopes in metadata.yaml > > They have different values. I could only find documentation for global > > and container. Global apparently is the default. So that is what I set > > it to explicitly. I'm quite sure that I had tried it with 'container' > > too in one of the iterations of testing. > > > > I can't really see how the interface class scope could have changed. It > > was always scope.UNIT. So I'm going to dig through some code to > > understand the implications of scope in metadata.yaml... > > > > > > Thanks Ales > > Tilman > > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > -- Alex Kavanagh - Software Engineer Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
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. Either I'm wrong to expect this to work and subordinates are only supposed to have container scopes. Then it is a dokufix and should be caugt by charm proof. Or, it is a bug. I could not find the point in the code which could be wrong here. If anyone points me to the right place I would not mind working on a fix. In go or python. Thanks Tilman PS: File as bug in LP? On 25.01.2017 11:00, Tilman Baumann wrote: > On 24.01.2017 16:56, Alex Kavanagh wrote: >> Hi Tilman >> >> (I'm not an expert here, but was staring at the docs) >> >> I suspect that your peers relationship should be unit if each peer needs >> to have it's own conversation? Otherwise, with a global scope, every >> peer will overwrite the other's information? At least I'm wondering if >> that what the scopes mean: see >> here: https://jujucharms.com/docs/2.0/developer-layers-interfaces >> >> If that's completely wrong, then a) sorry for the noise, and b) do tell, >> as it will help me in my understanding of juju scopes. > > No I think this must generally be the direction I need to think towards. > Any thought impulse in that direction can unlock the knot in my head. :) > > Thing is, my interface class is scope UNIT already. (GLOBAL and SERVICE > definitely would be wrong I think) > > What hasn't really connected in my brain is how this relates to the > scopes in metadata.yaml > They have different values. I could only find documentation for global > and container. Global apparently is the default. So that is what I set > it to explicitly. I'm quite sure that I had tried it with 'container' > too in one of the iterations of testing. > > I can't really see how the interface class scope could have changed. It > was always scope.UNIT. So I'm going to dig through some code to > understand the implications of scope in metadata.yaml... > > > Thanks Ales > Tilman > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
On 24.01.2017 16:56, Alex Kavanagh wrote: > Hi Tilman > > (I'm not an expert here, but was staring at the docs) > > I suspect that your peers relationship should be unit if each peer needs > to have it's own conversation? Otherwise, with a global scope, every > peer will overwrite the other's information? At least I'm wondering if > that what the scopes mean: see > here: https://jujucharms.com/docs/2.0/developer-layers-interfaces > > If that's completely wrong, then a) sorry for the noise, and b) do tell, > as it will help me in my understanding of juju scopes. No I think this must generally be the direction I need to think towards. Any thought impulse in that direction can unlock the knot in my head. :) Thing is, my interface class is scope UNIT already. (GLOBAL and SERVICE definitely would be wrong I think) What hasn't really connected in my brain is how this relates to the scopes in metadata.yaml They have different values. I could only find documentation for global and container. Global apparently is the default. So that is what I set it to explicitly. I'm quite sure that I had tried it with 'container' too in one of the iterations of testing. I can't really see how the interface class scope could have changed. It was always scope.UNIT. So I'm going to dig through some code to understand the implications of scope in metadata.yaml... Thanks Ales Tilman -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
Hi Tilman (I'm not an expert here, but was staring at the docs) I suspect that your peers relationship should be unit if each peer needs to have it's own conversation? Otherwise, with a global scope, every peer will overwrite the other's information? At least I'm wondering if that what the scopes mean: see here: https://jujucharms.com/docs/2.0/developer-layers-interfaces If that's completely wrong, then a) sorry for the noise, and b) do tell, as it will help me in my understanding of juju scopes. Cheers Alex. On Tue, Jan 24, 2017 at 3:46 PM, Tilman Baumann < tilman.baum...@canonical.com> wrote: > Any comments are appreciated. I'm stuck with this right now and I'm out > of ideas. > > Thanks > Tilman > > On 24.01.2017 14:44, Tilman Baumann wrote: > > [...] > > Any idea what could be happening here. > > I suspect something with the scopes. But they are now all set > > explicitly. Any changes in implicit behavior should not affect this. > > Am I expecting something from subordinate charms which they can not > provide? > > > > The ssh-peers-relation-* hooks are still called when a unit joins or > > leaves. But somehow it's information is not added to the conversation. > > Or rather, I think it replaces actually the currently visible single > > entry in there. > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > -- Alex Kavanagh - Software Engineer Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: normal charm to subordinate charm and now peer relation does not work
Any comments are appreciated. I'm stuck with this right now and I'm out of ideas. Thanks Tilman On 24.01.2017 14:44, Tilman Baumann wrote: > [...] > Any idea what could be happening here. > I suspect something with the scopes. But they are now all set > explicitly. Any changes in implicit behavior should not affect this. > Am I expecting something from subordinate charms which they can not provide? > > The ssh-peers-relation-* hooks are still called when a unit joins or > leaves. But somehow it's information is not added to the conversation. > Or rather, I think it replaces actually the currently visible single > entry in there. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
normal charm to subordinate charm and now peer relation does not work
Hi,
it became clear that my charm which was so far standalone (to be
installed together with other charms on the same machine) should better
be subordinate.
A few obvious changes where required regarding the life-cycle of the
charm. No big deal.
https://github.com/tbaumann/iptables-peer-ssh
However, suddenly the peer relation is behaving very oddly.
I'm only seeing one (arbitrary) peer unit in the relation.
This method only does one loop iteration and returns only one value.
def units(self):
hosts = []
for conv in self.conversations():
hosts.append(conv.get_remote('private-address'))
return hosts
The class has scope.UNIT scope.
class PeerDiscovery(RelationBase):
scope = scopes.UNIT
metadata.yaml specifies global scope for the peer relation.
peers:
ssh-peers:
interface: peer-discovery
scope: global
requires:
host-system:
interface: juju-info
scope: container
Any idea what could be happening here.
I suspect something with the scopes. But they are now all set
explicitly. Any changes in implicit behavior should not affect this.
Am I expecting something from subordinate charms which they can not provide?
The ssh-peers-relation-* hooks are still called when a unit joins or
leaves. But somehow it's information is not added to the conversation.
Or rather, I think it replaces actually the currently visible single
entry in there.
Here is the as of yet unpublished interface code.
https://github.com/tbaumann/charm-interface-peer-discovery
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
