16:30:11 #startmeeting kolla 16:30:12 Meeting started Wed Apr 6 16:30:11 2016 UTC and is due to finish in 60 minutes. The chair is sdake_. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:30:15 #topic rollcall 16:30:17 The meeting name has been set to 'kolla' 16:30:21 o/ 16:30:50 hi 16:30:51 o/ 16:30:57 hi 16:31:37 o/ 16:32:11 hi 16:32:48 giving it a ouple mins until everyone shows up :) 16:33:14 o/ 16:33:46 #topic announcements 16:33:56 we have 14 slots at openstack summit 16:34:07 4 o them are fishbowl 10 are design sessions 16:34:41 this is a huge haul for us 16:35:05 we also have a full day contributor meetup to handle overflow 16:35:11 so please try to attend friday as well 16:35:28 tuesday is the operator summit, i'd suggest attending that, since those folks are our target audience 16:35:40 monday is ops summit 16:35:45 tuesday is cross project summit 16:36:12 if your a core reviwer and wont make it to summit please let me know 16:36:42 #topic rc3 16:36:54 #undo 16:36:55 Removing item from minutes: 16:36:58 #topic 2.0.0 16:37:05 #link https://launchpad.net/kolla/+milestone/2.0.0 16:37:13 lots of bugs to fix 16:37:29 our original deadline is april 8th 16:37:42 however, we are apparently release indepndent so we hae no official deadline 16:38:00 i'd rather get the release right then wrong 16:38:20 i find it unlikely we will finish the bugs left in the 2.0.0 release by friday 16:38:25 i 16:38:35 i propose slipping a week 16:38:46 to give us more time to solve these critical last minute problems 16:39:41 any thoughts? 16:39:50 agree 16:39:56 agreed. 16:39:59 no thoughts 16:40:03 agree 16:40:14 sounds good 16:40:15 slipping a week means end of day April 15th ? 16:40:18 also thinks it's better to polish the release 16:40:41 vhosakot something like that 16:40:45 ok 16:40:58 in the meantime need people to stay focused on reviews 16:41:14 so we can get the patches that are in progress in the queue merged and backported 16:41:38 also there are many ununowned bugs 16:42:35 anyone have spare cycles top ick some up? 16:42:56 ya I'll grab a few 16:43:01 sdake_: I will pick some 16:43:41 ok, only assign yourself if you think you can get it fixed by the 15th 16:43:47 I also should be able to pick some 16:44:05 there are some esy ones, like documenting /etc/hosts 16:44:35 and hard ones ;) 16:44:53 #topic backport plans 16:45:08 the email thread kind of fizzled out 16:45:13 not sure what to do about that 16:45:35 here is what i' mthinking 16:45:35 inc0 is working on backports 16:45:37 I thought it was a go 16:45:38 he can continue to do so 16:45:54 pbourke- i think what the plan is is unknown atm :) 16:46:35 let inc0 focus on backport planning and sorting 16:46:35 and once he is done 16:46:37 as soon as we cut mitaka 16:46:42 we focus on the liberty backport as a team 16:46:55 distributing the work as necessary 16:47:38 i'd like mitaka done first, then liberty, all befoe summit starts ;) 16:48:00 mission impossible ftw ;) 16:48:17 have we finalized the list of things that will be back-ported.. I dont see it in inc0's latest mail http://lists.openstack.org/pipermail/openstack-dev/2016-March/091045.html 16:48:35 vhosakot my plan was to copy mitaka to liberty 16:48:44 and then fix liberty to point at the correct locations for sources 16:48:51 ah cool 16:48:56 and modif ythe templates as necessary to make it work and revert the keystone bootstrap change 16:49:08 i think folks wer ein general agreement with this 16:49:12 this is pasth of least resistance 16:49:25 and leverages our testing on mitaka and liberty 16:49:35 it kind of makes 1.0.0 a dead tag 16:50:12 sdake_: we are not backporting upgrades.. right ? 16:50:25 copy everything 16:50:30 ok cool 16:51:11 #topic demo slot at summit 16:51:28 akwasnie has a demo slot at summit 16:51:35 for logging 16:51:43 i think to mke that compelling we need a dashboard 16:51:55 yes with elemoine and inc0 16:52:06 sdake_, will the initial backport be one giant commit or a rebase? 16:52:15 akwasnie any luck on the dashboard? 16:52:20 mandre one giant commit i think 16:52:40 mandre i am really looking or a plan out of inc0 as to execution 16:52:46 he is leading the effort 16:53:02 that's also what I think is the easiest 16:53:17 it may be one giant commit plus a bunch of fixups 16:53:24 we were working on slides and did not manage to make a good dashboard, but hope we will do it soon 16:53:35 to address the locations and templates and ervert of bootstraping of keystone 16:54:07 akwasnie cool - folkks like to see something flashy in demos, so highy recommend spending time on a dashboard of some sort ;) 16:54:21 if you show them just kibana they will go "huh" 16:54:42 sdake_: yeah, you are right 16:55:17 i would coommit to helping ou but unfortunately i will be heavily involved in this backport effort 16:55:50 and getting our summit sessions in order which takes a couple days 16:56:25 #topic our performance 16:56:25 sure, np - I understand 16:56:29 so folks, we totally rock 16:56:40 our team is one of the strongest teams in openstack 16:56:44 not that its a competition 16:57:06 however, we are very strong, and I just want to remind everyone, what we have built together is fantastic 16:57:09 so, kolla needs a logo now ;) 16:57:14 we have found a bunch of latent bugs kind of at the end 16:57:16 vhosakot make one ;) 16:57:26 of our dev cycle 16:57:35 so dont sweat that, thats normal 16:57:38 lets get it fixed 16:58:00 kolla is well liked, but will be judged by how we handle our liberty backport and how well liberty and mitaka function for operators 16:58:17 3 more weeks to go until summit 16:58:28 keep up the steam - then we can have some rest ;) 16:58:39 #topic open discussion 16:59:19 anyone blocked anywhere? 16:59:21 our centos gate has been continously failing to boot a nova VM... http://logs.openstack.org/34/299534/2/check/gate-kolla-dsvm-deploy-centos-binary/41abd22/console.html#_2016-04-05_16_13_10_608 16:59:26 this issue is not seen in Ubuntu gate 16:59:47 centos binary or centos source? 16:59:56 qemu 2.3 fixes that ithnk ;) 16:59:57 binary 17:00:04 yes.. centos binary 17:00:13 my qemu 23 patch passed the centos gates 17:00:20 so here is the story on the gates 17:00:21 nice 17:00:21 ow 17:00:26 wow* 17:00:28 there are atleast 6 providers 17:00:32 vhosakot, in your link, the rabbitmq failed to start. 17:00:38 our gate scripts have to account for all of them 17:01:05 Jeffrey4l: yeah..it is seen in centos source many times in gate.. 17:01:19 sdake_: let me look at the gate results of qemu patch.. cool 17:01:24 vhosakot first step file a bug 17:01:29 yes 17:01:30 yea. I have filed a bug and make some debug. still do not know the root cause. 17:01:38 vhosakot, sdake_ i have done that. 17:01:43 ok sounds like Jeffrey4l has done that nm then 17:02:01 Jeffrey4l found an issue where mariadb logs are cosuming disk space due to recent merge.. I am fixing it 17:02:02 lets see what hapepns after qemu 2.3 is in the gate 17:02:13 just notice mandre take that bug. 17:02:16 I picked this bug, I'll be working on it 17:02:20 Jeffrey4l: do you have time after meeting to talk about general_log for mariadb 17:02:36 i might be hitting the same problem. i'm working on the bug that steve opened "can't boot VM with TLS enabled", but i can't boot a vm without TLS either right now. (centos/all-in-one) 17:02:46 vhosakot, np. But I still want to block it. 17:02:57 vhosakot current setting for mariadb logging will kill any prod environment 17:02:58 Jeffrey4l: let us block it... 17:02:58 dave-mcc_ i had that problem until i used qemu 23 :) 17:03:11 sbezverk: agreed 17:03:14 vhoskat ol has the same rabbit problem 17:03:16 Fyi 17:03:20 vhosakot, any idea to solve the disk consume? 17:03:29 Jeffrey4l: looking into it now 17:03:39 sdake_ is that config change? 17:03:52 dave-mcc_ patch (wip) 17:04:07 dave-mcc_ i'll link it - you can rebsae it under your current work 17:04:16 I am afraid not. moreover, log every query sql into the ELK is not a good idea. 17:04:17 Jeffrey4l: sbezverk let us talk after meeting... 17:04:33 np 17:04:35 Jeffrey4l: yes, no need to log _every_ query 17:04:55 is there any idea about how we can implement multiple backends? 17:05:10 mlima you mean pllugins? 17:05:14 multi backends for what? 17:05:18 cinder 17:05:19 yes sdake_ 17:05:33 yes vhosakot 17:05:35 mlima we will have summit planning sessions on that topic 17:05:42 what backends do you have ? lvm,ceph at the same time ? 17:05:56 vhosakot cinder has 50 backends or more 17:06:22 ok sdake_ 17:06:32 yea. that's not easy. how about launch multi cinder-volume container, each container support one backend? 17:06:39 cool, we can discuss in session plaaninf in summit 17:07:17 Jeffrey4l, yes 17:07:37 cinder-volume-lvm and cinder-volume-ceph 17:07:49 yes. something like that. 17:07:59 gets unwieldy 17:08:19 there are about 200 plugins we will have to deal with just with cinder, nova, neutron, and keystone etc 17:08:21 since we are on cinder topic, please try lvm2/iscsi, now it supports conditional volumes and should not break anything 17:08:49 Kolla need some plugin mechanism like devstack does. 17:09:16 you mean for other projects? 17:09:32 delegate part of the image/ansible role to the project or the end-user may be helpful. 17:09:49 Jeffrey4l good idea bad timing ;) 17:09:52 sdake_, for other projects or the cinder backend case. 17:09:59 sdake_, yea. I know that. 17:10:12 there are 200 plugins for various projects we haveto deal with ata minimum 17:10:13 but, cinder-volume-ceph, cinder-volume-lvm, cinder-volume-... is this a good idea ? 17:10:53 i think this model doesn't scale well 17:11:18 i'd rather have one container contain allt he plugins 17:11:22 we need not support all plugins sdake_ , let's leave that for anyone interested 17:11:46 yes.. and for plugins.. imagine... cinder-volume-netapp, cinder-volume-EMC... we need to dicuss in summit 17:12:10 ya irc is too low bandwidth to have an effective conversatoin about it 17:12:35 when _one_ cinder-volume can handle multiple backends, why can't it be true when the cinder-volume process is in a container ? 17:13:01 agreed, we can talk later 17:13:19 i think in one container for each backend 17:13:23 as long as "backend's binaries" can co-exist I do not see why not 17:14:22 anything else? 17:14:55 ok, we know what we need to do in priority order 17:14:58 1. finish job on mitaka 17:15:05 2. finish job on liberty backport 17:15:13 3. support our demo slot with a dashboard 17:15:25 lets get to it :) 17:15:27 thanks for coming 17:15:29 #endmeeting