17:02:17 <tinwood> #startmeeting charms
17:02:19 <openstack> Meeting started Mon Mar 20 17:02:17 2017 UTC and is due to finish in 60 minutes.  The chair is tinwood. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:22 <openstack> The meeting name has been set to 'charms'
17:02:36 <tinwood> Hello all.  Welcome to the openstack charms meeting.
17:02:52 <tinwood> roll call, so I know who's here :)
17:03:17 <tinwood> hello?
17:03:30 <icey> Hi :)
17:03:44 <beisner> o/
17:03:45 * sparkiegeek waves
17:03:59 <tinwood> Okay, lets get started.
17:04:15 <tinwood> #topic Review ACTION points from previous meeting
17:04:25 <jamespage> o/
17:04:34 <coreycb> o/
17:04:48 <tinwood> The only one we have is: ACTION: jamespage Draft initial proposal for service discovery
17:04:52 <tinwood> o/ jamespage
17:04:53 <jamespage> done
17:05:00 <tinwood> excellent!
17:05:04 <jamespage> hmm - but I think I need to write that up as a spec still
17:05:09 <tinwood> Is there a link?
17:05:28 <jamespage> https://etherpad.openstack.org/p/charms-service-discovery
17:05:32 <cholcombe> o/
17:05:34 <tinwood> ta
17:06:01 <tinwood> Okay, next topic:
17:06:23 <tinwood> #topic State of Development for next Charm Release
17:06:41 <tinwood> we're early in the cycle.
17:07:10 <tinwood> I'm still switching on some of the tests for automated testing.
17:07:22 <tinwood> Anyone want to comment on this?
17:07:26 <tinwood> (topic)
17:07:30 * beisner thanks tinwood and thedac ;-)
17:07:49 <beisner> i have a question on this topic
17:07:54 <beisner> pike is next
17:08:26 <beisner> i'd like to see us have a definitive checkpoint where we aim to have preliminary bits landed and sync'd in ahead of charm freeze.
17:08:46 <tinwood> do you mean like the bits I'm doing now?
17:08:49 <beisner> re: c-h version tables, c-h amulet helpers, amulet test definitions, etc.
17:08:51 <beisner> yes
17:09:28 <tinwood> Is there a reason we do them afterwards?  (e.g. they're not going to work beforehand)
17:09:48 <beisner> it doesn't have to be / shouldn't be flipped on as gating at that checkpoint, but we should have all of the series/codename bits flipped and landed so people can do a `func27-dev` and get those to run.
17:10:10 <beisner> tinwood, no reason other than 'its hard'(tm) when upstream bits are still flying in the days/weeks leading up to it.
17:10:20 <tinwood> that's a good reason :)
17:10:40 * sparkiegeek hands beisner a ™
17:10:56 <beisner> it is a bit chicken/egg.  in order for us to know where we stand, we need to have a certain baseline of things landed to make the mechanics of testing work.
17:11:13 <beisner> without that, we can't even deploy the next thing™
17:11:19 <tinwood> okay, beisner would you like an action to suggest a process that might work?  i.e. what sort of timeatable would work, etc.
17:11:28 <beisner> so i'd like to be able to deploy the next thing™ earlier this, and every cycle.,
17:11:34 <beisner> even if it's not known-good.
17:11:43 * beisner thanks sparkiegeek too
17:11:59 <jamespage> beisner: so like enabling xenial-pike now rather than later?
17:11:59 <beisner> tinwood, curious if there are thoughts already on this among those in the room
17:12:06 <beisner> jamespage, exactly.
17:12:16 <jamespage> beisner: but as part of dev first rather than gate
17:12:22 <beisner> or at some pre-determined checkpoint, such as R-N
17:12:29 <beisner> jamespage, exactly x 2
17:12:34 <coreycb> not amulet related, but we do have a to-do to enable CI from master branch PPAs for pike
17:12:35 <tinwood> could they be non-voting?
17:12:47 <beisner> coreycb, this is a prereq for that.
17:12:48 <tinwood> i.e. run automatically.
17:12:55 <icey> +1 for non voting early CI
17:12:56 <jamespage> beisner: its a shame we can't split up our full amulet run to report back individual results for each check/gate
17:13:14 <jamespage> then we could have a non-voting check on the development release stuff early in cycle
17:13:21 <beisner> jamespage, we can and we plan to.  ie. define each test in the project-config bits, rather than wildcard them in tox.
17:13:34 <jamespage> awesome
17:13:48 <jamespage> so dev vs gate is the current method for that right?
17:13:51 <beisner> yep
17:13:53 <beisner> dev-*
17:13:55 <jamespage> ok
17:13:57 <jamespage> +1
17:14:02 <beisner> a'ight thanks y'all
17:14:03 <tinwood> sounds good +1
17:14:15 <tinwood> so, any action out of that?
17:14:25 <jamespage> btw I did write the spec
17:14:26 <jamespage> http://specs.openstack.org/openstack/charm-specs/specs/pike/approved/service-discovery.html
17:14:42 <jamespage> rrd-brain
17:14:55 <beisner> tinwood, action would be to do what thedac's batch is doing now for ocata, but for pike immediately after.
17:14:58 <coreycb> beisner, not following the pre-req bit but i don't know if it's important
17:15:16 <beisner> coreycb, in order to test pike deploys from master pkg builds, the charms have to be pike-aware.
17:15:30 <tinwood> this feels bigger than a simple action. maybe we could open a bug to track it?
17:15:51 <coreycb> beisner, right but not necessarily amulet pike aware, although that would be nice
17:16:21 * sparkiegeek 's eyes twitch at "alot" in service-discover spec
17:16:28 <beisner> coreycb, correct, the two are not technically coupled.  but it makes sense to enable the dev-* amulets in the same batch, as there is no expectation that they pass or be gating.
17:17:01 <beisner> tinwood, this is really a routine issue, which we need to formulate and just-do each cycle.,
17:17:14 <beisner> and my trailing commas are due to a bandaid on my finger btw ;-)
17:17:29 <tinwood> beisner, I agree, but the initial work needs to be tracked somewhere, wouldn't you agree (i.e. to make sure it happens!)
17:17:35 <coreycb> beisner, that's true if we want to enable pike tests early in the cycle but i didn't think that was the plan
17:17:53 <beisner> tinwood, yep, wherever we track the "open the next version for development" list-o-stuff ™ to do.
17:18:29 <tinwood> okay, then I will leave it with you :) Any thing more on this topic before we move on?
17:18:38 <beisner> coreycb, depends on who's driving the batches.  if i'm driving, i'm flipping the bits in one pass vs two or three.
17:19:17 <coreycb> beisner, my point is that we want to do CI on a daily basis for pike starting soonish.  but will amulet tests be part of that for pike?
17:19:23 <beisner> tinwood, but i'm not convinced we have such a list-o-stuff list, so let's add an action to document the dev-cycle-opening task list?
17:20:06 <beisner> coreycb, fear not.  the CI daily won't be dependent on the amulet dev actually passing.  it'll be a blind bitflip so that people "can" exercise it.  whereas right now they "cannot."
17:20:22 <tinwood> #action beisner list-o-stuff™ concerning/documenting the dev-cycle-opening task list.
17:20:34 <beisner> then, at freeze or before it, hopefully pike has stabilized enough, and there is someone ready and available to go make sure they pass.
17:20:39 <coreycb> beisner, cool, i'd be +1 for non-voting pike enablement of amulet tests
17:20:41 * tinwood hopes the ™ didn't break the action bot
17:20:51 <beisner> :-)
17:21:06 <tinwood> Okay, next up:
17:21:13 <beisner> thanks guys and gals
17:21:23 <tinwood> #topic Discussion: service discovery vs modeling
17:21:29 <tinwood> jamespage, the floor ...
17:21:44 <jamespage> oh that's an old item - we already talked bout that
17:21:56 <jamespage> outcome was:
17:21:57 <jamespage> http://specs.openstack.org/openstack/charm-specs/specs/pike/approved/service-discovery.html
17:22:15 <tinwood> okay, wasn't sure whether it was a post spec discussion.  All is good :)
17:22:21 <tinwood> thanks
17:22:30 <jamespage> crufty agenda methings
17:22:35 <tinwood> #topic High Priority Bugs
17:22:44 <tinwood> OpenStack bugs at: https://bugs.launchpad.net/openstack-charms
17:23:49 <tinwood> critical/high = 69 bugs
17:24:11 <jamespage> its about 15% of total bugs
17:24:22 <jamespage> (453)
17:24:36 <jamespage> gosh did that in my head
17:24:51 <tinwood> 10 reported in the last year that are still open.
17:25:24 <sparkiegeek> in the last year = > 365 days old, or reported in 2016 ?
17:25:25 <jamespage> I think its worth everyone using their bug time to focus in on those bugs
17:25:26 <tinwood> (actually it may be more than that, due to sorting not working!)
17:25:44 <jamespage> it may be they are not classified correctly; or that they do need fixing
17:26:00 <jamespage> I'd encourage folk to leave 4hrs or so a week to bug triage
17:26:04 <tinwood> we have regular bug squash days.
17:26:21 <tinwood> jamespage, can I triage yet?
17:26:23 <jamespage> we have the monthly bug squash days as well
17:26:29 <jamespage> tinwood: you should be able to
17:26:37 <tinwood> okay, I will check
17:26:46 <jamespage> tinwood: yes you're in the right team
17:27:03 <tinwood> any bugs we want to discuss before moving on.  (we have 3 minutes)
17:27:09 <jamespage> nope
17:27:18 <jamespage> oh actually
17:27:45 <jamespage> I wanted to mention
17:27:45 <jamespage> https://docs.openstack.org/developer/charm-guide/1702.html#ceph-based-cinder-storage-backends
17:27:57 <jamespage> that was resolved as a post 17.02 stable update
17:28:03 * jamespage looks at sparkiegeek
17:28:24 <jamespage> I did raise this to dpb last week - just want to make sure one of our downstream projects is aware of that requirement for ocata
17:28:26 <sparkiegeek> jamespage: noted, thanks
17:28:40 <jamespage> yw
17:28:49 <tinwood> #topic Openstack Events
17:29:13 <tinwood> any comments on this?
17:29:34 <tinwood> if not:
17:29:45 <tinwood> #topic Open Discussion
17:29:56 <tinwood> floors anybody's
17:30:31 <icey> time to clear the floor?
17:30:39 <sparkiegeek> did my suggestion of updating/composing release notes as we go get anywhere?
17:30:52 <tinwood> is that relnote or similar?
17:31:12 <tinwood> because something got mentioned at the ptg
17:31:14 <jamespage> sparkiegeek: the reno stuf?
17:31:30 <jamespage> sparkiegeek: that's the intent but I think we're lacking an assignee atm
17:31:31 <sparkiegeek> jamespage: tinwood: ... maybe?
17:31:39 * tinwood thanks sparkiegeek
17:31:51 <tinwood> yes, I'll take a look.
17:31:53 <sparkiegeek> I didn't read notes from PTG (are they up somewhere?)
17:31:56 <jamespage> changes would land with the associated releasenote and we then generate them all
17:32:00 <tinwood> #action tinwood to look at reno
17:32:25 <jamespage> sparkiegeek: https://etherpad.openstack.org/p/openstack-charms-ptg-pike
17:32:34 <sparkiegeek> jamespage: thankns
17:32:59 <tinwood> anything else?
17:33:20 <tinwood> okay, thanks everybody.
17:33:25 <tinwood> #endmeeting