15:59:07 <inc0> #startmeeting kolla
15:59:08 <openstack> Meeting started Wed Nov 30 15:59:07 2016 UTC and is due to finish in 60 minutes.  The chair is inc0. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:12 <openstack> The meeting name has been set to 'kolla'
15:59:22 <inc0> #topic rollcall, w00t please!
15:59:23 <duonghq> w00t!!! o/
15:59:28 <wirehead_> meow
15:59:40 <rhallisey> meow meow
15:59:41 <duonghq> wirehead_, meo,,,,,
15:59:49 <inc0> lol
16:00:00 <Jeffrey4l> woot
16:00:05 <sbezverk> o/
16:00:52 <zhubingbing_> o/
16:00:53 <duonghq> I forgot or we have new kollish?
16:00:54 <sbezverk> sorry wirehead_ I am dog guy ;-)
16:01:02 <pbourke_> o/
16:01:07 <inc0> ^._.^
16:01:12 <berendt> o/
16:01:14 <jascott1> o/
16:01:22 <pbourke_> finally remembered the correct time
16:01:30 <berendt> pbourke_: dito :)
16:01:45 <inc0> yes, pbourke_ that would be hard for someone as far away from GMT as you are;)
16:01:53 <sayantani01_> w00t
16:01:54 <duonghq> nice to see both of you pbourke_, berendt
16:01:59 <portdirect> o/
16:02:16 <pbourke_> inc0: :P
16:02:18 <sdake> WOOT
16:02:34 <duonghq> sdake, WOOT finally?
16:02:38 <sdake> you got it
16:02:46 <inc0> #topic announcements
16:02:49 <sdake> one time only :)
16:03:37 <inc0> I have one. I'm going for PTO + moving across country from 6th Dec till pretty much holiday. I won't be around (will try to join in every now and then but can't promise)
16:04:01 <inc0> Jeffrey4l graciously agreed to help me and cover for me during this time
16:04:12 <sdake> Jeffrey4l ++
16:04:28 <zhubingbing_> ＋＋
16:04:38 <Jeffrey4l> may need some help from sdake  ;)
16:04:39 <inc0> so, if there is anything needing immediate attention, he's your guys. I'll also can be reached by email or just wait till I'm back
16:05:06 <inc0> anyway, that being said, let's kick this off by handing this meeting to Jeffrey4l
16:05:11 <inc0> #chair Jeffrey4l
16:05:11 <openstack> Current chairs: Jeffrey4l inc0
16:05:18 <inc0> you're up:)
16:05:40 <sdake> Jeffrey4l you got it
16:05:42 <Jeffrey4l> our agenda is not updated recently.
16:05:55 <inc0> yeah, that's not news;0
16:06:19 <inc0> so I can throw first topic
16:06:34 <Jeffrey4l> other annoucement from community?
16:06:42 <inc0> our voting of splitting core teams ends today and so far we seems to be in agreement
16:06:42 <sdake> on Jeffrey4l 's point - i think it would be helpful for everyone to update the agenda
16:06:52 <sdake> rather then relying on one person to do the job
16:07:03 <berendt> uh. looks like i missed this mail.
16:07:06 <portdirect> will do :)
16:07:28 <Jeffrey4l> re agenda: update the wiki page https://wiki.openstack.org/wiki/Meetings/Kolla before meeting please :)
16:07:34 <inc0> well not splitting cores
16:07:47 <inc0> that cores form kolla-ansible woudl vote for kolla-ansible cores and so on
16:07:52 <inc0> that's effectively team split
16:08:55 <Jeffrey4l> ok. next topic?
16:09:27 <Jeffrey4l> #topic heka alternative
16:09:39 <Jeffrey4l> this is talked in http://lists.openstack.org/pipermail/openstack-dev/2016-November/108011.html
16:09:44 <Jeffrey4l> recently.
16:10:00 <wirehead_> One might say we've discussed it a heka lot of times.
16:10:15 <sdake> wirehead_ lol
16:10:28 <Jeffrey4l> i think we need make the choice right now.
16:10:28 <Jeffrey4l> yep.
16:10:43 <Jeffrey4l> i think the fluentd win finally.
16:10:53 <sdake> Jeffrey4l right now or kick it to pike
16:10:54 <Jeffrey4l> any idea on this?
16:11:15 <sdake> i have a bit of concern about the short schedule we have in ocata
16:11:24 <Jeffrey4l> ok. yes.
16:11:28 <sdake> and not cratering kolla in the process
16:11:29 <berendt> i would prefer to work on it right now
16:11:34 <portdirect> +1 to Fluentd, simply beause a lot of k8s support is there
16:11:36 <sbezverk> hurray for fluentd ;-)
16:11:39 <sdake> ok - again just an opion
16:11:58 <berendt> fluentd works for me, i do not have a strong behavior..
16:12:01 <inc0> yeah fluentd is cool as it's cncf project now
16:12:05 <sdake> i'd recommend we work on a stack of patches rather then merging
16:12:11 <inc0> my reservations for fluentd were because of billing model afair
16:12:13 <berendt> sdake: +1
16:12:17 <Jeffrey4l> sdake, +1
16:12:27 <sdake> purupose of that is to hedge, in case the implementation doesn't work
16:12:30 <inc0> but as its cncf project now, that's done
16:13:06 <inc0> so for Snap credit, it will allow us to have similar functionality to heka in a month or so, as far as I know from team managing it
16:13:16 <inc0> but I understand, maturity
16:13:37 <berendt> i think we should try to make fluentd swapable
16:13:39 <sdake> we also have a general rule inc0 we adapt to our upstreams and don't wait for them to publish features
16:13:45 <berendt> that it is not a big deal to replace it in the future
16:13:54 <berendt> maybe we have the same issue with fluentd in a few months
16:14:01 <sdake> berendt no doubt about it ;)
16:14:15 <inc0> so yeah, I think that thing is swappable on it's own
16:14:17 <Jeffrey4l> #action migrate from heka fluentd with a stack of patches. merged until it works.
16:14:31 <sdake> not merged ?
16:14:36 <berendt> Jeffrey4l: will you send out an update to openstack-dev?
16:14:47 <sdake> Jeffrey4l you can use #undo to undo an action
16:15:04 <Jeffrey4l> #undo
16:15:05 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x7fbb93d96790>
16:15:10 <Jeffrey4l> #action migrate from heka fluentd with a stack of patches. not merged until it works.
16:15:11 <sdake> Jeffrey4l and then do the action again - merged until works doesn't mean what I think you meant it  to :)
16:15:17 <sdake> sweet :)
16:15:22 <portdirect> Jeffrey4l: s/untill/when
16:15:23 <Jeffrey4l> sdake, thanks.
16:15:31 <sdake> portdirect its gefn :)
16:16:12 <Jeffrey4l> why openstack-dev?
16:16:18 <Jeffrey4l> berendt, ^
16:16:42 <berendt> Jeffrey4l: we discussed it there and i think we should note that we decided to use fluentd
16:16:46 <sdake> Jeffrey4l so people know the action
16:17:03 <zhubingbing_> ＋1
16:17:05 <Jeffrey4l> should we send mail to openstack-ops, right?
16:17:18 <inc0> Jeffrey4l, let's send email when we merge stuff
16:17:21 <inc0> to ops
16:17:27 <berendt> inc0: +1
16:17:29 <Jeffrey4l> OK.
16:17:35 <Jeffrey4l> i will send the mail.
16:17:39 <inc0> as we might end up having some sort of strange technical issues
16:17:40 <inc0> never know
16:17:52 <Jeffrey4l> next topic is? i have no right now
16:18:12 <inc0> I wanted to talk about changes in core polict
16:18:21 <inc0> #topic core team policy change
16:18:28 <inc0> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/107457.html
16:18:55 <inc0> voting ends today eod, but so far it's unanimous +1 so I expect it to pass
16:19:15 <inc0> that effectively means that we will have separate core teams for all 3 deliverables
16:19:28 <inc0> kolla, kolla-k8s and kolla-ansible
16:19:34 <berendt> does this also mean that we split the meetings?
16:19:59 <inc0> no, meetings, irc channel, community is the same
16:20:04 <inc0> it's just for logistics of reviews
16:20:17 <portdirect> sounds good
16:20:43 <qwang> should we merge kolla and kolla-kubernetes?
16:20:49 <inc0> we work to clean up kolla-kubernetes core team to better show who really cares about project;)
16:20:58 <duonghq> qwang, no....
16:21:01 <inc0> qwang, no, both of them are separate
16:21:05 <inc0> same as ansible
16:21:06 <inc0> now
16:21:46 <sdake> inc0 the cleanup stuff is intenral core business - and shouldn't be discussed in the meeting fwiw :)
16:22:33 <inc0> well, fair enough;)
16:23:04 <inc0> anyway, most importantly core teams now will have ability to nominate and vote for their own memeber
16:23:05 <inc0> s
16:24:01 <portdirect> sdake / sbezverk: wanna talk about the progress on kolla-kubernetes helm?
16:24:10 <duonghq> +1 portdirect
16:24:24 <inc0> heh, I guess we exhausted this topic?;) ok, let's move on
16:24:42 <Jeffrey4l> #topic kolla-kubernetes helm
16:24:56 <sbezverk> finally we got into the agreement how helm temaplating will look like
16:25:01 <portdirect> +2
16:25:12 <duonghq> thank sbezverk, kfox1111  on it
16:25:36 <sbezverk> so with merging a couple of PS people will be able to replicate merged solution and start adding templates
16:26:13 <sbezverk> we have a white board with planned services/microservices please pick the one you like and go ....
16:26:34 <sdake> sbezverk i think the whiteboard is not filled out
16:26:48 <sdake> sbezverk i'll do that after this meeting assuming i don't have another ;)
16:26:56 <sbezverk> https://blueprints.launchpad.net/kolla-kubernetes/+spec/helm-microservices
16:27:12 <Jeffrey4l> do we have any example on how to do this? which will be helpful for others to join.
16:27:13 <sdake> ya no work items
16:27:24 <sdake> Jeffrey4l indeed that is what the whiteboard patchsets are
16:27:36 <sbezverk> sdake: oh so we did not move from helm-packages BP the whiteborad we had there?
16:27:39 <sdake> Jeffrey4l mind adding an action for me to fill out the work items
16:27:46 <sdake> sbezverk not whiteboard, the work items
16:27:52 <sdake> the whiteboared is for status udpates
16:27:58 <sdake> the work items are for organizing the work
16:28:01 <sbezverk> sdake: right
16:28:03 <Jeffrey4l> #action sdake add work item for bp helm-microservices
16:28:24 <Jeffrey4l> #link https://blueprints.launchpad.net/kolla-kubernetes/+spec/helm-microservices
16:28:35 <portdirect> I've also been working on a dev env, based on halycon-k8s, that I've started to docs for - so once kfox's work is merged in, i'll try and get that doc'd as well and we should be able to get a real head of steam up :)
16:28:42 <sdake> portdirect ++
16:29:05 <sdake> portdirect so your dev env, i'm using it
16:29:07 <sdake> what else is needed?
16:29:24 <Jeffrey4l> feel free to take some item from this bp. we'd better finish this before m2.
16:29:25 <sbezverk> good job portdirect, I saw the results of your doc in sdake testbed, looks good
16:30:03 <portdirect> not much really - though I'm gonna retire my halycon-k8s fork (hopfully today)
16:30:21 <portdirect> and document getting kubectl and helm clients installed on the localhost
16:30:40 <Jeffrey4l> anything else on this topic?
16:30:42 <portdirect> from there the workflow should be really easy for a developer to use
16:30:55 <jascott1> do we also need a setup_dev.sh ?
16:30:59 <wirehead_> yay. :)
16:31:24 <portdirect> jascott1: on it :)
16:31:29 <sdake> portdirect thats a great idea - kubectl and helm clients on lcoal host
16:31:45 <sdake> jascott1 defien setup_dev.sh for us :)
16:32:01 <portdirect> and destroy_dev.sh...
16:32:05 <jascott1> things from setup_gate.sh but for local dev
16:32:16 <portdirect> ^^
16:32:32 <sdake> one thing i'd like to ensure is we dont muck up developer systems with  a bunch of crap
16:32:38 <sdake> reference: devstack
16:32:45 <sdake> people run devstack in vms for a reason
16:32:54 <jascott1> there are these things called containers...
16:33:01 <sdake> i want to run kolla-kubernetes on my bare metal
16:33:09 <wirehead_> Yeah, making kollak-k8s not be like devstack was a very large motivator. :)
16:33:39 <sdake> rahter i want to do dev of kolla-kubernetes on bare metal
16:33:44 <inc0> I have an idea, let's deploy it with kolla and it will be all great
16:33:46 <sdake> if that means its in a vagrant box on my localhost
16:33:46 <portdirect> sdake: thats very close :)
16:33:47 <sdake> thats cool
16:33:55 <rhallisey> this is what I used: https://github.com/kubernetes/kube-deploy/tree/master/docker-multinode
16:34:17 <sdake> portdirect what you got now is good for devs
16:34:21 <rhallisey> only issue for multinode is you need a 2nd bm machine or a vm
16:34:28 <sdake> portdirect setup_dev.sh may be good too - have to see in review :)
16:34:34 <portdirect> the vagrant is just setting up come vm's to then run ansible on - I'll document running on baremetal...
16:34:48 <sdake> portdirect nah thats not what i meant
16:35:12 <sdake> portdirect your docs are perfect from my pov +/- some deltas
16:35:30 <duonghq> rhallisey, it's a good option
16:35:54 <sdake> portdirect devs dont want their systems destroyed by the development environment
16:36:00 <rhallisey> if you have 1 vagrant box setup to run https://github.com/kubernetes/kube-deploy/blob/master/docker-multinode/worker.sh
16:36:00 <sdake> which in essence, is what devstack does
16:36:12 <rhallisey> & run on your host: https://github.com/kubernetes/kube-deploy/blob/master/docker-multinode/master.sh
16:36:18 <portdirect> sdake: +1
16:36:46 <sdake> portdirect so keep at it, my only recommendaiton there is to keep setup_dev.sh whtaever that is, constrained to not installing a bajillion things :)
16:37:15 <sdake> portdirect i think your docs are pretty close to mergeable now as is but we can sort that out in gerrit
16:37:27 <sdake> portdirect if you do a setup_dev.sh would you do it in a followup?
16:37:56 <sdake> whenever i see setup_dev.sh I think "setup_devSTACK.sh" :)
16:38:19 <portdirect> sdake: yeah - it wont do anything other than setup kubectl and helm clients
16:38:22 <Jeffrey4l> #link https://github.com/kubernetes/kube-deploy/tree/master/docker-multinode
16:38:40 <sdake> rhallisey v1k0d3n and crew have produced a nice development environment that we are using as an upstream
16:38:53 <rhallisey> cool
16:39:14 <sdake> i really like it alot
16:39:22 <jascott1> me too
16:39:51 <Jeffrey4l> let's move on?
16:39:56 <sdake> runs on one node - simualtes multiple nodes, fast to setup, fast to teardwon
16:39:56 <portdirect> rhallisey: kube-deploy is better for production  (ATM at least in my opnion) - but this is just for getting a quick and dirty mutinode env up and running
16:40:02 <sdake> hits all the checkboxes ;)
16:40:28 <portdirect> Jeffrey4l: yeah
16:40:31 <sdake> Jeffrey4l sure
16:40:32 <rhallisey> nice
16:40:37 <Jeffrey4l> #open discussion
16:40:46 <sdake> oh wait one moment jeffrey4l
16:40:54 <sdake> maybe i wasn't paying attention
16:41:08 <sdake> did we have the kolla-kubernetes topic?
16:41:16 <Jeffrey4l> sdake, we are just now.
16:41:39 <sdake> ok in open discussion - wfm :)
16:41:42 <Jeffrey4l> but it is marked as `kolla-kubernetes helm`
16:41:47 <srwilkers_> o/
16:41:48 <sdake> oh i see.
16:41:55 <sdake> ok, well i'll do a general update here in open discussion
16:41:55 * srwilkers_ is very late
16:41:56 <sdake> sup srwilkers_
16:41:58 <portdirect> srwilkers_: o/
16:42:04 <sdake> srwilkers_ its ok - volunteer effort :)
16:42:20 <Jeffrey4l> anyone want talk?
16:42:25 <sdake> basically the plan is to crank out the microservices
16:42:42 <sdake> after the microservices are done
16:42:48 <sdake> we will move up a layer to thte service layer
16:42:55 <sdake> how that works is to be defined
16:43:00 <duonghq> can we set the topic back to helm?
16:43:08 <sdake> thats all I have duonghq :)
16:43:16 <portdirect> so - I have a topic that may be controversial re ceph
16:43:31 <duonghq> sdake,  I think we should refer to rhallisey specs
16:43:56 <sdake> duonghq agree - there  is no spec for this part of the system
16:44:21 <duonghq> in rhallisey's specs, we have 4 option, seem that we nearly have consensus no option 4 (iirc)
16:45:05 <sdake> duonghq moment let me read the spec
16:45:30 <portdirect> should we continue to maintain kolla-k8s ceph - or make use of the work that the ceph team are doing upstream? - Not a strong opioninion either way but seems like we are replicating effort.
16:45:43 <duonghq> #link https://review.openstack.org/#/c/392257/
16:45:59 <Jeffrey4l> #link https://review.openstack.org/#/c/392257/
16:46:23 <sdake> portdirect on the containers aspect, we must use our containers
16:46:44 <sdake> portdirect the ceph containers themselves don't do ubuntu for example
16:46:45 <rhallisey> did want to mention one thing real quick
16:46:46 <Jeffrey4l> portdirect, does ceph fro upstream runs on k8s?
16:47:39 <portdirect> Jeffrey4l: yes and they have a good set of templates
16:47:43 <rhallisey> dealing with some internal stuff so i'll be around here and there
16:47:58 <vhosakot> sorry I joined late
16:47:58 <rhallisey> just wanted everyone to know where I've been
16:48:06 <duonghq> vhosakot, o/
16:48:09 <sdake> portdirect got a link
16:48:12 <vhosakot> o/
16:48:14 <portdirect> but sdake's point clarifyted the policy I was unsure of - so I'll keep on it
16:48:21 <rhallisey> sdake, had kindly agreed to take the helm
16:48:36 <jascott1> snare drum crash
16:48:37 <Jeffrey4l> rhallisey, nice ;)
16:48:46 <portdirect> sdake: https://github.com/ceph/ceph-docker/tree/master/examples/kubernetes
16:48:52 <sdake> portdirect thanks
16:48:56 <sdake> i'll check it out
16:49:02 <Jeffrey4l> #link https://github.com/ceph/ceph-docker/tree/master/examples/kubernetes
16:49:05 <rhallisey> wirehead_, did you see that pun ^
16:49:13 <sdake> we dont want to duplicate work that is happening upstream, no
16:49:18 <rhallisey> where's the applause?
16:49:30 <sdake> although if the work happening upstream conflcts with our rchitecture, we are forced into it
16:49:37 <portdirect> rhallisey: are you here all week :D
16:49:49 <rhallisey> hehe
16:49:57 <duonghq> rhallisey, awesome
16:49:58 <sdake> rhallisey applause :)
16:50:38 <srwilkers_> rhallisey, oh i see what you did there
16:51:02 <sdake> ok duonghq when I said move up a lyaer, I wasn't talking about moving up the layer to operators
16:51:12 <sdake> I was talking about moving up a "sub-layer" in layer-3
16:51:14 <portdirect> sdake: it would be very eay to take what we needed and put them in our containers though - I've been working on that
16:51:46 <sdake> duonghq as in services next - all part of the helm layer - layer 3
16:52:18 <duonghq> sdake, got it
16:52:23 <sdake> portdirect there are CLA problems with that
16:52:47 <sdake> the work submitted to the repo must be original work of your own, not someone elses
16:53:05 <duonghq> so the rhallisey's operators in review queues need waiting little more time?
16:53:12 <sdake> that is unless they have also signed the cla :)
16:53:18 <portdirect> sdake: roger
16:53:26 <sdake> duonghq i think that operators can be worked in parallel
16:53:35 <rhallisey> duonghq, it's in decent shape
16:53:39 <sdake> duonghq if people want to get on that, wfm :)
16:53:42 <rhallisey> it was meant to be a foundation
16:54:23 <duonghq> sdake, rhallisey we have some diverse in sort out operator and helm stuff in bp organization?
16:54:43 <sdake> duonghq that didn't parse
16:54:58 <sdake> specifically diverse
16:55:13 <duonghq> sdake, I mean for the operators, we have 1bp/operator, but for helm stuff, we have 1bp/layer
16:55:16 <sdake> do you mean that the launchpad needs better organiation?
16:55:18 <rhallisey> the bps for each operator hasn't been made
16:55:32 <sbezverk> duonghq: confused a bit, what we do with helm now is perfectly fits with operator concept
16:55:52 <rhallisey> should do a bp per operator service
16:55:57 <rhallisey> since that work will be split up
16:56:00 <sdake> disagree
16:56:02 <sbezverk> where operator would call helm install microservice to deploy what ever it needs
16:56:07 <sdake> the best way to handle that is work items
16:56:11 <sdake> one master blueprint
16:56:39 <rhallisey> whatever works
16:56:46 <sdake> well its the openstack way :)
16:56:53 <duonghq> sbezverk, we are talking about "layer" in rhallisey's spec
16:57:17 <rhallisey> I roll my own way :)
16:57:19 <duonghq> sdake, okay
16:57:48 <Jeffrey4l> time almost up  2 min
16:58:45 <sdake> duonghq happy to have further conversation with you to clear things up after meeting since we are short on time
16:58:49 <sdake> in #openstack-kolla
16:58:53 <rhallisey> also
16:58:57 <duonghq> sdake, sure
16:59:02 <rhallisey> got a new name for operators
16:59:04 <rhallisey> vessels
16:59:13 <rhallisey> mariadb vessel
16:59:16 <sdake> make it harder ;)
16:59:21 <duonghq> rhallisey, didn't got your idea
16:59:26 <duonghq> *get
16:59:42 <rhallisey> sdake, operator is hard enough
16:59:47 <rhallisey> it means 2 things
17:00:10 <Jeffrey4l> ok. time is up
17:00:19 <Jeffrey4l> thanks people for coming
17:00:34 <Jeffrey4l> #endmeeting