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