17:01:51 <gnuoy> #startmeeting charms 17:01:52 <openstack> Meeting started Mon Jul 11 17:01:51 2016 UTC and is due to finish in 60 minutes. The chair is gnuoy. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:56 <openstack> The meeting name has been set to 'charms' 17:02:00 <gnuoy> \o 17:02:05 <beisner> o/ 17:02:06 <thedac> o/ 17:02:16 <tinwood> o/ 17:02:16 <gnuoy> #topic Review ACTION points from previous meeting 17:02:24 <gnuoy> #subtopic gnuoy move meeting to openstack-meeting channel 17:02:31 <beisner> Woot 17:02:33 <gnuoy> Well, I did \o/ 17:02:36 <tinwood> yay 17:02:38 <thedac> \o/ 17:02:46 <gnuoy> hurray for me. 17:02:54 <beisner> yes :-) 17:02:55 <gnuoy> #topic State of Development for next Charm Release 17:03:05 <gnuoy> So...*Thursday* 17:03:35 <gnuoy> We need to be finishing features off or punting them for three weeks 17:03:53 <gnuoy> Designate should be up for review tomorrow PM 17:04:09 <gnuoy> I think Barbican should be done soonish too 17:04:26 <gnuoy> Anyone got any big changes up their sleeves that they want to come clean about? 17:04:31 <tinwood> Barbican will hopefully be ready by Wednesday inc. some func tests. 17:04:45 <gnuoy> kk 17:04:57 <gnuoy> #topic High Priority Bugs 17:05:23 <gnuoy> Rabbit and Percona are the two big ones that have come up recently 17:05:35 <gnuoy> I believe thedac has crushed the percona one 17:05:45 <gnuoy> I will grab that review 17:05:56 <beisner> we do need to refactor the percona-cluster amulet tests to cover more than just trusty-icehouse 17:05:57 <tinwood> nice thedac :) 17:05:57 <gnuoy> and jamespage has fixed the rabbit one 17:05:59 <thedac> #link https://review.openstack.org/#/c/339823/ 17:06:01 <beisner> yes big thx thedac 17:06:25 <gnuoy> beisner, shall we try and do that real-soon-now or in a few weeks? 17:06:32 <jamespage> o/ 17:06:35 <coreycb> o/ 17:06:44 <thedac> I verified jamespage's rabbit fix. It is good. 17:06:48 <beisner> not sure if we can squeeze that in for 16.07 (pxc) ... i know i don't have bandwidth atm to take that on. but it does need to happen, sooner the better 17:07:02 <gnuoy> beisner, ack, lets push it out then 17:07:03 <jamespage> beisner, test for xenial? 17:07:08 <beisner> jamespage, ack 17:07:19 <jamespage> I might be able todo that - assign me the bug 17:07:48 <gnuoy> jamespage, general refactor 17:07:56 <gnuoy> but xenial is defo needed 17:08:03 <beisner> ref: https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1546577 17:08:03 <openstack> Launchpad bug 1546577 in percona-cluster (Juju Charms Collection) "pxc charm needs amulet test coverage refactor" [High,Confirmed] 17:08:09 <gnuoy> #action jamespage add xenial tests to percona-cluster 17:08:25 <beisner> er um 17:08:26 <beisner> #link https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1546577 17:08:49 <jamespage> got it 17:08:52 <gnuoy> ta 17:08:55 <gnuoy> moving on ... 17:09:05 <gnuoy> #topic Tox target for layers 17:09:27 <gnuoy> jamespage, beisner Ithink you said you were going to defer a discussion to here on that ? 17:09:35 <gnuoy> or am I imagining that? 17:09:48 <jamespage> oh yes - that's right 17:10:10 <jamespage> so this came up because the layer jobs are currently configured to run a build target as part of check/gate 17:10:14 <beisner> ok, so do we want to require all layer repos to (a) have a build tox target; and (b) expect success in building ? 17:10:29 <gnuoy> What does the build do ? 17:10:41 <jamespage> gnuoy, pulls the layer + its dependencies together 17:10:42 <gnuoy> assemble the lower layers? 17:10:48 <gnuoy> ack 17:10:49 <tinwood> why would a layer have a build target? 17:10:52 <jamespage> so if someone stuff in a bad interface or layer, this would gate that 17:11:13 <jamespage> I think ideally we've have this are part of a layer lint tool 17:11:16 <gnuoy> I feel a bit shruggy about it but I don't object 17:11:19 <jamespage> layer proof or siuchlike 17:11:29 <beisner> tinwood, that's the nature of the convo. i was also surprised by it. but jamespage pointed out that it is potentially a valuable test (to build it). 17:11:42 <jamespage> but right now, the only way todo this is to 'build' the layer (and then throw it away) 17:11:46 <beisner> aiui, the "src charm" is the only thing we'll ever build, deploy-test and publish, right? 17:11:52 <jamespage> ack 17:12:01 <gnuoy> yep, I think so 17:12:30 <jamespage> so - build target in layers (to be superceeded by lint later) 17:12:36 <gnuoy> ok, unless anyone objects lets go with a build target to check dependancies can be assembled 17:12:38 <jamespage> is that agreed? 17:12:43 <jamespage> +1 17:12:45 <gnuoy> +1 17:12:45 <thedac> +1 17:13:12 <beisner> i'm good with that - please do document it somehow, perhaps a tox.ini #comment 17:13:34 <gnuoy> kk. I'll take silence from others as 0 17:13:34 <beisner> my only holdback here is that a non-openstacker gets ahold of a layer repo, sees a build target, builds it, tries to deploy it, fails, etc. 17:13:56 <gnuoy> beisner, agreed, lets spew out a comment/warning 17:14:03 <jamespage> sure 17:14:15 <beisner> or ... perhaps more confusingly ... an openstacker tries to create a layer which can be both a built charm AND a layer to consume. 17:14:32 <beisner> i'm just looking for good ways to make it crystal clear. 17:14:41 <jamespage> we're trying to avoid that situation :-) 17:15:04 <beisner> i sniff the desire to do just that with the ceph-*s. 17:15:37 <jamespage> hmm 17:15:42 * jamespage ponders this a bit longer 17:15:44 <tinwood> I thought that had been quashed and a thin src charm was the idea for the ceph-* 17:16:08 <beisner> i think that is the right answer tinwood - while they layer "could" be a layer or a charm, it "shouldn't" 17:16:14 <tinwood> maybe 'quashed' isn't the right word for it. 17:16:27 <thedac> politely suggested? 17:16:31 <tinwood> indeed. 17:16:52 <beisner> need to make sure everyone's in line with: for every layered charm we produce, there shall be a src charm. and, solved. :) 17:16:53 <icey> my understanding is the same as tinwood, src charm that has a built layer on top of it 17:17:17 <icey> the top layer for (for example) ceph-mon would be a layer that just includes the ceph-mon layer 17:17:20 <gnuoy> kk 17:17:42 <tinwood> can it be 'enforced' though? Only in the publish step, i would say? 17:17:54 <beisner> where charm-ceph-mon is a src charm and charm-layer-ceph-mon is just a layer. beautiful. 17:18:12 <thedac> We might want to disucss naming conventions. Ceph-mon layer vrs src charm should'b both be named ceph-mon 17:18:12 <jamespage> tinwood, basically if you don't comply with the 'interface' which is to have src, your charm/layer won't work with the CI 17:18:14 <icey> beisner: I think it'd just be charm-ceph-mon uses layer-ceph-mon 17:18:15 <icey> ? 17:18:42 <jamespage> we have to prefix due to a single openstack namespace 17:18:42 <beisner> charm-layer-ceph-mon should be the namespace aiui 17:18:42 <tinwood> jamespage, that is very sensible. 17:19:00 <jamespage> ok - so build is OK 17:19:07 <gnuoy> ok, I think we are in agreement 17:19:08 <jamespage> this is not unchangeable btw 17:19:10 <tinwood> yes, I've come around to the idea :) 17:19:17 <gnuoy> ok, lets move on 17:19:20 <jamespage> if we all hate it in two weeks time that ok 17:19:20 <gnuoy> #topic 2 x +2 17:19:25 <jamespage> yeah ok 17:19:30 <gnuoy> another of jamespages 17:19:40 <jamespage> so this came up in the governance review for project status 17:19:48 <gnuoy> #link https://review.openstack.org/#/c/224797/ 17:19:59 <jamespage> most openstack projects operate 2 x +2's prior to workflow +1 17:20:18 <jamespage> we're not operating that currently - just a single +2 is required for workflow +1 17:20:55 <jamespage> I *think* that we should do the 2x +2, but it will have a small overhead on throughput of changes 17:20:55 <tinwood> Is it a blocker then? 17:21:09 <jamespage> no its not a blocker as far as we can tell 17:21:40 <thedac> jamespage: Does +1 and then a +2 make more sense? Or does it have to be 2 x +2? 17:21:41 <tinwood> ah, okay, so it's up to us. 17:21:41 <beisner> i'm actually good with a single +2 given the size of our group 17:22:05 <beisner> additional +1s or +2s are always a good thing though 17:22:30 <gnuoy> I'm leaning towards beisners view until the core reviewer base is bigger 17:22:30 <jamespage> agreed - and maybe we do this on a per change basis - if its something contentious or a config flags or relation data change we do 2x 17:23:00 <beisner> yah i think we've effectively done that, asking for cross-reviews for hairy changes. 17:23:03 <gnuoy> kk, but its something we should keep an eye on 17:23:19 <thedac> that makes sense and we have basically been doing that. Waiting for a second opinion on complex changes 17:23:23 <beisner> indeed. we could sure do 2 x +2s if it's a thing or desired. 17:23:28 <jamespage> I think that is fair as well - if/when we get a more diverse reviewer base, then this will be more powerful, ensuring that no single person could drive a change objective not aligned to the project 17:23:41 <cholcombe> i agree, single +2 is enough for us. The reviewer base is too small 17:23:43 <gnuoy> yep, that makes sense 17:23:51 <jamespage> ok 17:23:55 <gnuoy> ok, onwards and upwards 17:23:58 <gnuoy> #topic Openstack talk submissions for ODS 17:24:04 <gnuoy> When was that deadline again? 17:24:10 <jamespage> this week 17:24:13 <jamespage> thursday I think 17:24:18 <gnuoy> ack, ta 17:24:40 <beisner> #link https://www.openstack.org/summit/barcelona-2016/call-for-presentations/ 17:24:53 * beisner quotes: JULY 13, 2016 AT 11:59PM PDT (JULY 14 6:59 UTC) IS THE DEADLINE TO SUBMIT A TALK. 17:25:35 <gnuoy> Thanks beisner 17:25:40 <jamespage> that's wednesday to be clear 17:25:45 <gnuoy> yep 17:26:07 <gnuoy> Get your thinking caps on 17:26:24 <gnuoy> #topic Open Events 17:26:38 <gnuoy> Any other Openstack and/or charm events coming up? 17:27:17 <gnuoy> Ok, moving on 17:27:22 <gnuoy> #topic Open Discussion 17:28:35 <gnuoy> Going Once 17:28:50 <gnuoy> Going Twice 17:29:00 <beisner> Sold! thanks, gnuoy 17:29:03 <gnuoy> #topic Announce next meeting date, time and chair 17:29:22 <gnuoy> Two weeks time, on Monday at 17:00 UTC 17:29:25 <gnuoy> Same place 17:29:31 <gnuoy> chair thedac I believe 17:29:36 <thedac> I am up 17:29:42 <gnuoy> #endmeeting