16:30:06 <sdake> #startmeeting kolla
16:30:06 <openstack> Meeting started Wed Jan 13 16:30:06 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:09 <sdake> #topic rollcall
16:30:09 <openstack> The meeting name has been set to 'kolla'
16:30:19 <akwasnie> hi
16:30:21 <sdake> \o!/ hi!!
16:30:32 <elemoine> o/ hi
16:30:39 <Jeffrey4l> \o/
16:30:45 <dratushnyy> \?/
16:31:36 <SamYaple> o/
16:32:06 <rhallisey> hi
16:32:08 <inc0> o/
16:32:49 <jpeeler> hi
16:32:57 <sdake> #topic announcements
16:33:25 <sdake> 1. midcycle is february 9th, february 10th in greenville sc
16:33:46 <sdake> I will publish full wiki info today if I can - have had contractors at my hosue dealing with my reemodel so i've been distracted
16:34:03 <sdake> there will be breakfast, lunch both days
16:34:09 <sdake> there will be dinner on tuesday night
16:34:21 <sdake> so your real only expenses should be travel and hotel
16:34:50 <sdake> if someone is on the fence bout not being able to make it because of budget, I am willing to share rooms if you can handle the snoring - just ping me later
16:35:05 <sdake> along with the share rooms, i'll pick up the full tab
16:35:15 <sdake> for the room so that just leaves airfare
16:35:24 <sdake> woud like to have a good turnout for our core reviewers
16:35:40 <sdake> any other announcements sfrom the community?
16:35:49 <sdake> oh one more
16:36:08 <sdake> 2. I have assked sam to act as a backup tagger in case I fall off a cliff like which happened in december
16:36:16 <sdake> he tagged milestone 1
16:36:22 <sdake> everyone give sam a round of applause please :)
16:36:37 <inc0> <round of applause>
16:36:41 * kproskurin claps
16:36:47 * Jeffrey4l claps
16:36:57 <rhallisey> yay!
16:37:11 * elemoine claps
16:37:14 <jpeeler> yay sam
16:37:15 <dratushnyy> *claps*
16:37:17 <sdake> finally 3. january 21 is our deadline for mitaka 2 - so please finish up any tasks you want to tackle :)
16:37:39 <sdake> #topic midcycle planning
16:37:46 <sdake> timebox 10 minutes
16:38:01 <sdake> lets finalize the agenda for the mitaka midcycle
16:38:14 <sdake> anyone have the link handy where we have been doing that work?
16:38:41 <sdake> i had to reset chrome and lost all my cached pages
16:38:51 <elemoine> https://etherpad.openstack.org/p/kolla-mitaka-midcycle ?
16:39:02 <sdake> #link https://etherpad.openstack.org/p/kolla-mitaka-midcycle
16:39:14 <sdake> please open and we will run until 50 after
16:39:34 <sdake> if your a new contributor, please add your name to the list of contributors
16:39:41 <sdake> (to the planning)
16:40:40 <rhallisey> sdake, do we want to have some ordering here on importance?
16:40:54 <sdake> rhallisey i have that later in the agenda
16:40:58 <sdake> and i'll combine those
16:40:59 <rhallisey> kk
16:43:13 <sdake> actually rhallisey good point
16:43:29 <sdake> I'd like peoiple to vote on sessions they want - just in case time is tight
16:43:38 <sdake> we hae done this in the past - and I forgot we did, but it worked well
16:43:52 <sdake> so please add your nick followed by +1/-1
16:43:55 <rhallisey> sdake, let me organize it real quick
16:44:02 <sdake> dont organize it
16:44:08 <sdake> just leave as is
16:45:06 <SamYaple> hear that harmw. no alphabetizing!
16:45:07 <rhallisey> sdake, can't really read it
16:45:31 <sdake> rhallisey i will sort it out after the meeting
16:45:34 <rhallisey> pl
16:45:35 <rhallisey> ok
16:45:38 <sdake> we only ahve 5 minutes left, i'd like to ge the evoting in
16:45:49 <sdake> look at my exampless
16:45:53 <sdake> +0 is a vote as well :)
16:48:15 <sdake> folks please vote quickly - 2 minutes left
16:48:43 <sdake> ok i'll send followup to the ml asking for our team to vote :)
16:49:59 <sdake> 1 more minute
16:50:05 <sdake> ok timers up :)
16:50:14 <sdake> #topic heka discussion
16:50:31 <sdake> sorry this is out of order because inc0 has to leae shortly
16:50:41 <sdake> so apparently heka get rid of rsyslog
16:50:43 <sdake> which seems good
16:50:47 <SamYaple> sdake: you are not following the agenda
16:50:54 <sdake> SamYaple i know, see abovve
16:51:01 <elemoine> not fully sure
16:51:02 <SamYaple> ah there you go
16:51:08 <elemoine> about removal of rsyslog
16:51:17 <inc0> elemoine, you mentioned it will listen on stdout
16:51:27 <sdake> SamYaple  all good now?
16:51:36 <elemoine> right
16:51:38 <sdake> some services don't output to sstdout
16:51:39 <SamYaple> for the record inc0 im not sold on listening on stdout for logs
16:51:52 <SamYaple> i rasied some concerns about that
16:51:58 <elemoine> yeah, mariadb writes to /dev/log (syslog) for example
16:52:09 <SamYaple> in the case of say neutron there is neutorn and dnsmasq logs
16:52:12 <sdake> elemoine do you have a solution in mind for that problem?
16:52:13 <SamYaple> one container
16:52:14 <inc0> SamYaple, right, however if we make this work (that's my requirement) it might be better than rsyslog
16:52:26 <inc0> can heka support both?
16:52:29 <inc0> at the same time?
16:52:40 <inc0> some containers stdout some /dev/log?
16:52:58 <inc0> or other streams if needed?
16:53:18 <elemoine> at the moment, and given sdake's latest email, keeping rsyslog may make sense actually
16:53:22 <sdake> if heka can't capture /dev/log in some cases, it seems like a non starter
16:53:22 <inc0> with rsyslog we can handle more-or-less everything. It's not ideal but it's working
16:53:47 <elemoine> inc0, right and we can easily log to files as well
16:53:58 <elemoine> which is a requirement as I understand
16:54:04 <sdake> ya thats the other thing, we need logs to files per node
16:54:09 <inc0> elemoine, file logging is actually temp solution
16:54:18 <inc0> before we get centralized logging in place
16:54:19 <SamYaple> inc0: no.. it was permanat
16:54:23 <SamYaple> even with central logging
16:54:27 <SamYaple> logs stay per node too
16:54:27 <sdake> inc0 i'd like to keep it for mitaka at minimum
16:54:36 <elemoine> we want both: log to local files + send logs to ES
16:54:42 <inc0> ok, in any case, we want it as well before we get centralized logging
16:54:46 <sdake> elemoine  SamYaple  agree +1
16:54:49 <SamYaple> operator side central logging is good, but local logging is required
16:54:57 <elemoine> yep, agree
16:55:05 <kproskurin> Local loging will require this logs rotation and so on
16:55:09 <inc0> but both heka and rsyslog does that, so I guess that's that
16:55:10 <sdake> the other requirement is multiline logs
16:55:18 <inc0> what I'm interested in is logging sources
16:55:24 <SamYaple> well thats more parsing than anything sdake
16:55:26 <kproskurin> And local logs will eat space
16:55:42 <inc0> kproskurin, you can turn it off, but you should be able to have it
16:55:43 <sdake> kproskurin we decided long ago we need locl node logging
16:55:46 <SamYaple> kproskurin: understood. and maybe we have an option to turn it off
16:55:53 <SamYaple> but it has to be there
16:55:56 <sdake> i'm good with an option
16:56:00 <sdake> but it needs to be present
16:56:05 <kproskurin> Oh with turn off switch I guess its ok
16:56:18 <akwasnie> with my ELK patch we give user a choice rsyslog or ELK
16:56:28 <inc0> anyway, I'm -1 on having heka AND rsyslog as heka require compute node agent
16:56:35 <elemoine> akwasnie, one may want both
16:56:35 <sdake> akwasnie do you disable rsyslog entirely then?
16:56:42 <inc0> and I want to limit this as much a as possible
16:57:03 <sdake> it sounds like we need to have more mailing list discussion
16:57:05 <SamYaple> I think this is still complex. well need a working implemntation i think
16:57:06 <akwasnie> no, I can have both or each of them,
16:57:07 <sdake> i knwo everyone just got up in the us
16:57:07 <inc0> akwasnie, you need something that will forward logs from node to ELK
16:57:19 <sdake> so please, lets sort it out on the mailing list
16:57:22 <elemoine> sdake, no, with akwasnie's path logs go to files if elk is not enabled, and they go to ES if elk is enabled
16:57:28 <sdake> i think elemoine has an idea of the requirements we have
16:57:50 <elemoine> yeah it's quite clear, thank you sdake for putting those requirements together
16:57:50 <sdake> are there other requirements we have which are unstated thus far?
16:57:57 <akwasnie> elemoine: yes,
16:58:02 <sdake> inc0 akwasnie ?
16:58:19 <sdake> i dont want to wait to the midcycle to begin implementation on a poc of this work
16:58:20 <inc0> I don't want 2 agents for logging on compute node
16:58:22 <inc0> either or
16:58:38 <sdake> inc0 which two agents - could you define them please
16:58:41 <elemoine> sdake, I'd like to fully understand the multiline logs problems you have
16:58:58 <sdake> SamYaple can you explain thato elemoine ?
16:59:06 <inc0> hega agent and rsyslog agent
16:59:08 <sdake> basiclly backtraces are multiline
16:59:12 <sdake> and rsyslog eats them i think
16:59:20 <inc0> sdake, it does not now
16:59:27 <inc0> but it doesn't break lines
16:59:27 <sdake> oh cool you fixed that?
16:59:34 <inc0> so we have rsyslog traces but ugly
16:59:38 <inc0> not me, dims did
16:59:42 <SamYaple> sdake: its not the logging agent that logs them thats teh problem, its the log parser that needs to PARSE them thats the issue
16:59:44 <inc0> it was bug on oslo side
16:59:45 <sdake> nice well thats solid then
16:59:46 <elemoine> sdake, rsyslog currently replaces newline chars with a special char
17:00:26 <sdake> elemoine so the last unstated requirement it sounds like is we dont want *both* rsyslog and heka
17:00:42 <sdake> has to be one or the other
17:00:51 <sdake> SamYaple ack on the agent parsing
17:00:53 <SamYaple> clarkb did make a good point on the mailing list about replacing logstash. if we do we can't benefit from the logstash code that currently parses the openstack logs
17:01:13 <SamYaple> so i think we should acknowleged that at the very least
17:01:23 <sdake> SamYaple agree i must have missed that point
17:01:30 <sdake> that sounds like another requirement for heka
17:01:37 <SamYaple> we will have to write new filters and maintain them
17:01:51 <SamYaple> it may be worth it, but it may not. i dont know
17:02:00 <sdake> our team is big enough to handle thta SamYaple
17:02:00 <elemoine> we do have heka code for decoding openstack logs
17:02:14 <sdake> elemoine fantastic
17:02:34 <sdake> ok, i'll take an action to parsse this discussio nand publish the requirements in a new thread
17:02:45 <elemoine> we've been relying on them for some time now, and we know they work well
17:02:53 <sdake> #action sdake parse irc discussion and get requiremetns on the mailing list for the record
17:02:57 <SamYaple> cool elemoine. i beileve you. I jsut wanted to point it out
17:03:15 <sdake> ok anything else on this topic?  we are running short on time ;)
17:03:51 <elemoine> let's continue on the mailing list then
17:03:54 <akwasnie> for me nothing more
17:03:55 <sdake> elemoine i'd like the spec started asap please
17:04:12 <elemoine> let's finish the current ml discussions first
17:04:16 <sdake> our specs process requires majority vote of core reviewers for approval
17:04:19 <elemoine> then I'll start working on the specs
17:04:21 <sdake> elemoine sounds good
17:04:40 <elemoine> ok, cool
17:05:12 <sdake> moving on now
17:05:16 <sdake> #topic Kolla-mesos code sharing with kolla and kolla-ansible
17:05:25 <SamYaple> ill start this one
17:05:26 <sdake> SamYaple was this you that added to agenda?
17:05:29 <SamYaple> yes
17:05:51 <SamYaple> So me and nihilifer have notice a great deal of duplicate code in kolla-mesos and (what will be) kolla-ansible
17:06:01 <SamYaple> the code has been copy-paste moved
17:06:08 <sdake> SamYaple  you have the floor ;)
17:06:20 <SamYaple> what this has caused is things that get fixed in kolla-ansible code do not get fixed in kolla-mesos
17:06:23 <SamYaple> thanks sdake
17:06:36 <SamYaple> so we need to figure out a better way of code sharing so that doesnt happen
17:06:50 <sdake> should this be a midcycle discussion topic?
17:07:06 <SamYaple> very possible it should be
17:07:07 <nihilifer> i see at least 2 potential things to share
17:07:22 <nihilifer> 1) major, sharing ansible modules
17:07:23 <rhallisey> err this may be a problem we can't wait on then
17:07:29 <nihilifer> 2) minor, sharing vagrant
17:07:58 <sdake> just added to the etherpad
17:08:20 <SamYaple> hmm nihilifer this is more comlpicated, should we just wait for the midcycle?
17:08:21 <rhallisey> I thought this could be punted until N, but maybe not
17:08:23 <sdake> for midcycle further discussion
17:08:28 <rhallisey> SamYaple, I think so
17:08:40 <SamYaple> sdake: can we get an assured block of time?
17:08:49 <sdake> depends on the voting
17:09:00 <SamYaple> rhallisey: i think it needs to be discussed long before N
17:09:04 <SamYaple> its only getting worse
17:09:09 * jpeeler agrees
17:09:30 <sdake> the more votes the sessions get, moves up to tuesday in the agenda and at primier times
17:09:31 <rhallisey> SamYaple, I was hoping we wouldn't need to do until N, but given what you're saying probably can't wait
17:09:42 <SamYaple> if we cant get a block of time for the midcycle we should really do it now
17:09:49 <sdake> i am not keen to split the repos until upgrades are done
17:10:04 <SamYaple> that requires reviews
17:10:07 * SamYaple should make a bot
17:10:19 <sdake> ok if this is something mandatory that needs discussion, I'll make time in the agenda for it
17:10:27 <sdake> sounds mandatory
17:10:31 <SamYaple> I believe it is
17:10:37 <SamYaple> if so then we can move on right now
17:10:45 <sdake> ok moving on then :)
17:11:03 <sdake> #topic python-kollaclient - are we proceeding with this?
17:11:31 <sdake> i am not sure if folks read my email thread related to the abandonment of the cli codebase waiting on mesos and ansible integration
17:11:46 <sdake> if you didn't, you should read it please
17:11:57 <SamYaple> I added that before the ML thread when fungi asked about it
17:12:00 <SamYaple> the topic that is
17:12:19 <sdake> but in essence the maintainers of the cli don't want to commit to one cli when mesos is on the horizon
17:12:26 <sdake> so for hte time being, we are putting this work on hold
17:12:33 <sdake> unless unicorns come and implement it for us
17:12:44 <sdake> i am removing it as a deliverable from our governance repository
17:12:52 <sdake> this can always be undone later
17:13:09 <fungi> thanks again SamYaple for bringing it up for discussion. i mostly wanted to make sure it wasn't hiding under a different name or something such that i was missing counting your contributors
17:13:23 <SamYaple> appreciate that fungi
17:13:28 <sdake> fungi appreciated :)
17:13:50 <sdake> fungi did you see my mailing list discussion on the topic?
17:14:07 <sdake> it wasn't really a discussion more like an announcement
17:14:16 <fungi> sdake: yep, appreciated the details. 5 months in governance with no corresponding repo or even a patch to create it struck me as anomalous
17:14:33 <sdake> fungi it was going to go in then i had the tooth infection
17:14:47 <sdake> then mesos picked up steam and the contributors of the cli dont want to commit to it any longer
17:14:54 <fungi> i remember, that sounded terrible and dangerous. glad we've got you back now
17:16:24 <sdake> ok then any questions or shall I move on?
17:16:33 <SamYaple> move on i think
17:16:42 <SamYaple> my questions have been answered
17:16:54 <sdake> #topic priorities discussion
17:17:11 <sdake> so I added a midcycle session for this, please vote on it :)
17:17:23 <sdake> but basically my #1 priority is upgrades, my #2 priority is diagnostics
17:17:36 <sdake> I wanted to poll the core reviewers for their list of priorities
17:17:57 <sdake> part of this is to help me ramp back up from my december hiatus
17:18:05 <SamYaple> #1 upgrades #2 split repo for kolla-ansible (this will also help kolla-mesos)
17:18:28 <sdake> i'd like all core reviewers to respond please
17:18:33 <sdake> and in fact an ycontributors as well
17:18:54 <sdake> time box 7 inutes - so start typing :)
17:18:56 <nihilifer> #1 upgrades #2 split repo
17:18:57 <rhallisey> ditto SamYaple
17:19:28 <jpeeler> #1 upgrades, #2 split repo
17:19:45 <sdake> nobody seems to care about diagnostics :)
17:19:51 <jpeeler> maybe
17:19:53 <jpeeler> #3
17:19:54 <SamYaple> i do, its just not top priorites
17:20:01 <SamYaple> thats #3 for me (tied with ssl)
17:20:04 <jpeeler> see
17:20:08 <elemoine> I do care, but I'm not able to go to midcycle :)
17:20:20 <akwasnie> sdake: #1 upgrade, #2 diagnostics for me:)
17:20:23 <sdake> elemoine roger what is your opinion on prioirties then
17:20:26 <nihilifer> ditto, diagnostics is #3 for me
17:21:02 <sdake> so we have upgrades, diags, split repo, ssl
17:21:06 <elemoine> #1 upgrades, #2 diagnostics & split repo
17:21:07 <sdake> any other candidates?
17:21:19 <Jeffrey4l> #1 upgrade #swift #diagnostics :) ( care the produce issue more.)
17:21:29 <SamYaple> when docker 1.10 lands we can do neutron thin containers
17:21:32 <sdake> Jeffrey4l what do you mean swift?
17:21:34 <SamYaple> thats kinda a priority
17:21:37 <Jeffrey4l> s/produce/product/
17:21:39 <Jeffrey4l> yep.
17:21:43 <sdake> SamYaple cool
17:22:10 <elemoine> SamYaple, what Docker feature do you want to leverage?
17:22:39 <SamYaple> elemoine: private/shared mount namespaces
17:22:42 <sdake> Jeffrey4l what part of swift doessn't work for you now with kolla?
17:23:03 <SamYaple> it merged in 1.7-rc1 and was removed in 1.7-rc3. itttsss baaaaccckk
17:23:04 <elemoine> SamYaple, thanks, I need to look into that
17:23:12 <sdake> nice ;)
17:23:45 <sdake> ya thin containers for neutron would be win - need to sort out how to get that implemented
17:23:53 <Jeffrey4l> sdake, I haven't tested it detailly. But i am care about it.
17:23:56 <sdake> any other candidates for priorities?
17:24:04 <sdake> Jeffrey4l it worked when I tested it
17:24:04 <SamYaple> elemoine: https://github.com/docker/docker/pull/17034
17:24:11 <elemoine> and https://github.com/docker/docker/issues/10088
17:24:32 <sdake> ok sounds like we are all pretty much on same page
17:24:33 <Jeffrey4l> sdake, so why it is in the topics.
17:24:39 <sdake> so I'm going to move on
17:24:59 <sdake> Jeffrey4l  for autobuilding rings
17:25:07 <sdake> i think that can wait until N
17:25:14 <Jeffrey4l> roger
17:25:21 <sdake> #topic open discussion
17:25:29 <sdake> 5 minutes
17:25:36 <sdake> sorry so little time for open discussion - we had a packed agenda
17:26:19 <sdake> anyone want the floor?
17:26:36 <ajafo> got short question - maybe it'll need to discuss -  does we care about situation with rebuild only one container with for example added some packages (e.g. someone want to have sth additional installed in some docker container), because if yes it can broke dependencies in some situations
17:27:11 <sdake> we can rebuild just one container with our current build tools ajafo
17:27:21 <ajafo> I know but
17:27:46 <ajafo> lets imagine that someone want only rebuild nova_compute container with add some package in dockerfile, in the meantime were some updates in repository distribution repository, now if he is in ubuntu he get 404 no such package, and he know that he need to rebuild everything, but if he use centos then this one container will update own dependencies and install packages in other version than are in other containers, so we care about it or no? Is the rule
17:28:10 <SamYaple> ajafo: we do that though
17:28:12 <SamYaple> even now
17:28:24 <sdake> we rebuild all dependent cotnainers
17:28:28 <sdake> that is required for correct operation
17:28:59 <sdake> so that scenario yo ujust laid out, I am pretty sure can't happen
17:29:14 <ajafo> it just happend
17:29:19 <ajafo> with ubuntu
17:29:28 <sdake> ok, ajafo please post a discussion on the mailing list
17:29:31 <sdake> we are out o time :)
17:29:31 <elemoine> maybe another subject for the mailing list
17:29:33 <ajafo> ok
17:29:45 <sdake> thanks for your time folks :)
17:29:51 <sdake> and lets rock greenville :)
17:29:53 <sdake> #endmeeting