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