18:01:09 <sputnik13> #startmeeting cue
18:01:09 <openstack> Meeting started Tue Nov  3 18:01:09 2015 UTC and is due to finish in 60 minutes.  The chair is sputnik13. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:13 <openstack> The meeting name has been set to 'cue'
18:01:15 <sputnik13> role call!
18:01:24 <sputnik13> o/
18:02:29 <esmute__> o/
18:03:00 <sputnik13> this will be a short meeting if no one else shows up :)
18:03:10 <abitha> o/
18:04:47 <sputnik13> davideagnello role call
18:06:19 <sputnik13> alright, so, last week was summit week, we had 2 exciting design sessions between vipul and I
18:06:33 <sputnik13> actually there was one person from cisco that just dropped in because he was bored :)
18:06:49 <sputnik13> let's do our standard action items, bugs, then open discussion
18:06:57 <davideagnello> o/
18:07:08 <sputnik13> #topic Action Items
18:07:40 <sputnik13> #info AI #1 davideagnello to work on multi-broker-support https://blueprints.launchpad.net/cue/+spec/multi-broker-support
18:08:00 <sputnik13> that's done, check
18:08:16 <davideagnello> how did the design review go?
18:08:21 <sputnik13> there's some details we discussed in the etherpad from the design session
18:08:25 <sputnik13> #link https://etherpad.openstack.org/p/mitaka-cue-multi-broker
18:08:27 <davideagnello> ok
18:08:37 <sputnik13> let's talk about that during open discussion
18:08:39 <davideagnello> looked at that last week after your session
18:08:42 <davideagnello> ok
18:08:58 <sputnik13> #info AI#2 sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka
18:09:04 * sputnik13 kicks the can further
18:09:11 <sputnik13> #action sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka
18:09:26 <sputnik13> #info AI#3 dkalleg to provide details in https://blueprints.launchpad.net/cue/+spec/status regarding more accurate rabbitmq status check
18:09:34 <sputnik13> where is dkalleg?
18:09:53 <davideagnello> not in the office yet
18:09:58 <sputnik13> ok
18:10:10 <sputnik13> looks like it's not done yet
18:10:59 <sputnik13> ok, that's it for previous actions, bugs next
18:11:18 <sputnik13> no wait, agenda says discussion first then bugs, doh
18:11:25 <sputnik13> been so long since we've had discussion topics :)
18:11:42 <sputnik13> #topic Discussion Topics - Mitaka design session
18:12:32 <esmute__> how was the design review?
18:12:35 <sputnik13> so, we had 2 design sessions, it was pretty good overall in that it wasn't just vipul and I
18:12:51 <davideagnello> nice
18:12:52 <sputnik13> it was vipul, myself, and the one guy from cisco...  I should have gotten his name :(
18:13:06 <esmute__> any new people who participated?
18:13:09 <sputnik13> he was more an Ops focused person so we got some good feedback
18:13:19 <sputnik13> esmute__ ^ 1 person
18:14:07 <sputnik13> one of the areas of feedback was in how to configure things like brokers, there's a preference for configuration via config files rather than API
18:14:41 <sputnik13> some of the rationale being
18:14:47 <davideagnello> ok, moving away from DB type configuration
18:14:50 <esmute__> i think we will be going with config_file to start
18:14:59 <sputnik13> 1) it's easier to version control files
18:15:33 <sputnik13> 2) it's easier to migrate configuration between environments (dev, test/qa, production) when they're files
18:15:36 <esmute__> dbaas does it though configs as well... they have ini groups for each datastore
18:15:42 <esmute__> s/dbaas/trove
18:15:47 <sputnik13> right
18:16:33 <sputnik13> that brought up the question of what about new features that are being added/configured
18:16:37 <esmute__> did you guys discuss on any other topics?
18:16:40 <esmute__> new features?
18:16:43 <davideagnello> how would persistence of the config files work in this case?
18:16:44 <sputnik13> when you have code and config on each node you could get in to cases where a single node has updated code/config and the others don't
18:16:44 <esmute__> new brokers?
18:16:54 <davideagnello> or backup
18:17:36 <sputnik13> and the response was that as long as the op knows about the need to stagger restart the nodes they can handle directing traffic to the node with new code while others are restarted
18:17:55 <sputnik13> as long as the restart is quick it won't impact anything significantly
18:18:07 <sputnik13> no other topics with respect to other features or broekrs
18:18:55 <sputnik13> anyway, I think the two points above were good feedback that we hadn't really considered, and it's good to know that we don't have to necessarily worry about synchronizing deployment of new code/features
18:19:10 <sputnik13> it just needs to be well documented, and we have to ensure our restart times don't go up
18:19:33 <esmute__> ok
18:20:46 <sputnik13> before that vipul and I also talked about how brokers should be implemented as code rather than configuration
18:21:07 <sputnik13> we can go in to details about that during planning for the multi-broker feature
18:21:30 <davideagnello> ok
18:21:56 <sputnik13> the second design session was just a continuation of the first so there's nothing in the etherpad for that,
18:22:08 <sputnik13> we kept it all in the single etherpad
18:22:33 <sputnik13> that's it for the design session, do we have other discussion topics?
18:23:08 <sputnik13> if not let's go on to bugs...
18:23:10 <davideagnello> zookeeper OOM (Java heap space) we have seen?
18:23:26 <sputnik13> @davideagnello that's a bug right?
18:23:43 <sputnik13> let's file that as a bug
18:23:46 <davideagnello> looks like, possibly miss configured or use of zookeeper
18:23:50 <davideagnello> ok
18:23:54 <sputnik13> and I think I have a couple different solutions
18:24:16 <sputnik13> no I think based on what I've read about why you get in to OOM with zookeeper, it's more in how we're using it
18:27:44 <davideagnello> ok
18:28:06 <sputnik13> looks like there are no new bugs
18:28:14 <sputnik13> other than the zookeeper OOM
18:28:38 <davideagnello> yup
18:28:39 <sputnik13> that's definitely a critical bug we need to address
18:28:51 <sputnik13> since cue won't stay up for very long unless it's addressed
18:29:20 <sputnik13> can we discuss the details offline?
18:29:28 <vipul> o/
18:29:34 <sputnik13> I need to take care of something
18:29:45 <sputnik13> vipul welcome, fashionably late :)
18:29:51 <vipul> that's how i roll
18:29:52 <sputnik13> we're pretty much done
18:30:11 <vipul> nice.. great meeting!
18:30:12 <sputnik13> just need to discuss the zookeeper OOM issue
18:30:33 <sputnik13> let's do that in a little bit...  I have to take care of something
18:30:34 <vipul> yea we need to patch cue to split out the storage backend to db at the very least
18:30:36 <vipul> ok
18:30:44 <sputnik13> there's at least 2 ways we can solve the problem, I'll detail that in the bug
18:30:54 <sputnik13> davideagnello can you file the bug on launchpad?
18:32:40 <sputnik13> alright, I'm going to call it unless anyone has something else to discuss
18:32:49 <sputnik13> record time! 30 minutes :)
18:32:57 <sputnik13> going once...
18:33:03 <davideagnello> ok
18:33:05 <sputnik13> going twice...
18:33:20 <sputnik13> #endmeeting