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