[Review Queue] ODOO, ZNC, Dokkuwiki, ibm-platform-symphony-master, ibm-http
Greetings! The ~containers team took a stroll through the review queue today and reviewed several submissions. We had some findings and the full report can be found below: ZNC Charm Review: (Disapprove Vote) By @cynerva Had a look through the ZNC charm submitted by adam-stokes. The charm looks to be in great shape overall, but currently has an issue where the charm doesn’t expose the port used by ZNC, so for the time being I had to give it a -1. Once that is resolved I think we’ll be good to go. https://review.jujucharms.com/reviews/24?revision=173 Dokuwiki Charm Review: (Disapprove Vote) By @ryeterrell This charm is looking quite good. Had to give it a -1 for now because of the port exposure issue. https://review.jujucharms.com/reviews/22?revision=127 Ibm-platform-symphony-master (Abstain vote) By @mbruzek Did another review of this charm, needs homepage and bug-url set along with addressing old review comments. https://review.jujucharms.com/reviews/15 Ibm-http (Disapprove -1) By @mbruzek Has a test term “lorem-ipsum” in the list, need to remove and repush this charm without the test term. https://review.jujucharms.com/reviews/33 IBM-HTTP (Disapprove -2) By @lazypower There were a few issues here regarding zero byte resources, html entites in the readme, and a few suggestions to improve user experience around deploying this charm, (such as the use of min-juju-version in the metadata, and using proper terms as called out by mbruzek) -1 at this time. Odoo Charm Review: (Abstain Vote) By @lazypower Did another review of the Odoo charm submission by mistoebe. The charm has been vetted quite well, and only has one remaining blocking bug regarding its automated testing suite. There is an open pull request, which I briefly touched to keep contact alive and bump it in their notifications. Pending that PR acceptance, I have to abstain for now. https://review.jujucharms.com/reviews/23?revision=50 Charles Butler - Juju Charmer Come see the future of modeling your datacenter: http://jujucharms.com Conjure up Kubernetes: `conjure-up canonical-kubernetes` on any ubuntu install with Conjure and 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 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
Peers vs Members vs Terminology vs Usability
Trying to use the peers interface to coordinate all units of an application to know about each other, I find myself feeling like this should be a built in functionality. In other words, "tell me who my peers are" shouldn't turn into a giant milestone for every charm who needs to know what peers it has (skewed usage of peers here per Juju definition of peers). I feel like there are a decent number of charms/applications that will end up recreating this functionality independently (or already have), to the extent that we should probably think about making this functionality more built in/generic. My understanding for what a peer is, is different than what Juju defines a peer to be, hence we should think about defining some terminology around the term 'peer'. Possibly there is just a need for a generic 'members' interface built off the peers interface, which would do the coordination and caching bits, and make some basic information available to each member about its complimentary members? Thoughts? -- 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
