15:59:32 <inc0> #startmeeting kolla
15:59:33 <openstack> Meeting started Wed Sep 27 15:59:32 2017 UTC and is due to finish in 60 minutes.  The chair is inc0. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:37 <openstack> The meeting name has been set to 'kolla'
15:59:49 <inc0> #topic w00t!
15:59:56 <inc0> \o/ wooo!
16:00:01 <egonzalez90> wO0t!
16:00:10 <spsurya__> w00t!\0/
16:00:17 <krtaylor_> o/
16:00:24 <Jeffrey4l> woot
16:00:58 <duonghq> o/
16:01:10 <hrw> morning
16:01:12 <duonghq> \o\ /o/ -o-
16:01:19 <duonghq> evening guys
16:01:56 <britthouser> 0/
16:03:05 <inc0> #topic announcements
16:03:14 <inc0> I don't have any:)
16:03:18 <inc0> community?
16:03:21 <vhosakot> o/
16:03:28 <coolsvap> o/
16:03:37 <inc0> guess not
16:03:45 <inc0> #topic ptg recap continued
16:03:54 <inc0> afair we didn't do kolla-k8s last time
16:04:24 <britthouser> that's what I remember
16:04:31 <inc0> so biggest one was https://etherpad.openstack.org/p/kolla-queens-ptg-k8s-release-roadmap
16:04:37 <inc0> we revised 1.0 requirements
16:05:31 <inc0> I won't dig into that today
16:06:06 <britthouser> Should we make each of those main bullets into a blueprint? or?
16:06:21 <inc0> we also met with tripleo guys and discussed cooperation - there seems to be lots of potential there, but tripleo needs to design their k8s model
16:06:36 <inc0> britthouser, well, we don't have to
16:06:48 <britthouser> sounds good.
16:07:00 <inc0> process is for us, not we for it
16:07:17 <inc0> I, for one, like lightweight form etherpads
16:07:30 <inc0> anyway, that's what we need to do over next 6 months
16:07:43 <inc0> since there is no value to release 1.0 prior to release of openstack
16:07:51 <inc0> (well less than 6 months)
16:08:00 <duonghq> inc0, so, we cannot share our design with tripleo?
16:08:01 <inc0> bottom line, we're aiming for Rocky
16:08:05 <inc0> Queens*
16:08:25 <inc0> duonghq, well, some of it yes, but they aren't interested in helm
16:08:55 <duonghq> how about our k8s resources?
16:09:14 <inc0> helm renders them
16:09:27 <inc0> our k8s resources are represented as helm charts
16:09:47 <duonghq> understood
16:09:48 <inc0> they can use this knowledge tho, and I thin they will
16:09:55 <inc0> anyway, let's move on
16:10:29 <inc0> #topic ansible-become and keystone upgrade (duonghq)
16:10:34 <inc0> shoot duonghq
16:10:47 <duonghq> ah, nice, thank inc0
16:11:12 <duonghq> first, about the ansible-become bp, it's from last 2 cycle
16:11:39 <duonghq> so, due to it's beginning of Q, can somebody let it merge, and we will fix issue (if any) soon
16:11:52 <duonghq> due to it's not a small change
16:11:59 <duonghq> #link https://review.openstack.org/#/c/398682/
16:12:02 <duonghq> it's 1st ps
16:13:26 <duonghq> can I get some opinions?
16:14:12 <inc0> I'll review it first thing after meeting
16:14:23 <duonghq> thank inc0
16:14:27 <duonghq> about my 2nd topic,
16:14:53 <duonghq> implement upgrade mechanism of Keystone
16:14:54 <duonghq> https://review.openstack.org/#/c/425446/
16:15:19 <duonghq> this ps does not reach zero-downtime acctually (due to container restart at the same time)
16:15:42 <duonghq> but it's 1st step to implement mechanism from keystone,
16:16:06 <duonghq> the 2nd step is create new repo for ansible plugins
16:16:11 <duonghq> and apply new strategy
16:16:27 <duonghq> I hope that I can push it soon in Q
16:16:28 <inc0> or document to use --forks 1
16:16:55 <duonghq> inc0, or integrate it in our CLI?
16:16:58 <duonghq> as default option
16:17:06 <inc0> forks 1 should never be default
16:17:22 <inc0> it will make deployment at scale incredibly long
16:17:46 <britthouser> is there a way to make it default for only upgrade playbooks?
16:18:02 <inc0> we don't want to make it default there too
16:18:05 <duonghq> so, I think 1.5st step is add the documentation to use --forks 1 (before we can figure out some way to do better solution)
16:18:16 <inc0> because for this single use case it will make upgrade well...incredibly long
16:18:16 <egonzalez90> will make compute upgrades long too
16:18:34 <inc0> and time is even more critical in upgrade scenario
16:18:40 <britthouser> yeah I guess not all upgrades need to be sequential like that.
16:19:00 <inc0> only this single service really
16:19:03 <duonghq> sure
16:19:10 <inc0> also downtime we're looking at is sub-secondf
16:19:32 <duonghq> hmm, we need it for any service which implemented zero-downtime mechanism by their self
16:19:42 <inc0> technically we can just drain connections for this task
16:20:03 <inc0> if we impmelent haproxy connection draining
16:20:03 <duonghq> inc0, you mean we do it at haproxy-layer?
16:20:06 <inc0> right
16:20:16 <inc0> that will be apparent zero downtime
16:20:34 <inc0> rabbitmq will handle non-api services
16:20:53 <duonghq> so we need draining the connection, a little buffering and we get zero-downtime?
16:21:01 <inc0> between draining and graceful shutdown we should be good
16:21:18 <duonghq> we still have small time windows when we do not have any api-service available
16:21:30 <duonghq> and haproxy doesn't have retry ability
16:21:34 <egonzalez90> Yeah, but need allow admin socket in haproxy
16:21:49 <egonzalez90> Sec guys will not like that
16:22:11 <inc0> during service restarts you'll always have this risk
16:22:38 <inc0> well, let's do research ok?
16:22:47 <duonghq> nice
16:22:57 <inc0> I mean for full zero downtime we'll need that anyway
16:23:12 <inc0> to make sure haproxy won't forwards requests to api while it's restarting
16:23:36 <inc0> there's always lag between service down and haproxy noticing that
16:23:49 <duonghq> in other words, we need haproxy hold the request for awhile
16:24:06 <inc0> and with our speed whole upgrade of container can be faster than this notice period
16:24:47 <duonghq> so, I'll try and get you some measure
16:24:55 <inc0> thanks Duong
16:25:24 <duonghq> btw, from Boston summit, I have a small demo about buffering layer
16:25:47 <duonghq> ok, that's all from me
16:25:49 <duonghq> :)
16:26:09 <duonghq> after finish with keystone, I'll move to neutron
16:26:44 <egonzalez90> keystone change worked, duonghq and myself tested during PTG
16:26:57 <inc0> #topic Doc restructure (krtaylor)
16:27:07 <inc0> krtaylor you ahve the floor
16:27:11 <krtaylor_> Thanks inc0
16:27:36 <krtaylor_> Quick update: I created an etherpad and blueprint for the doc restructure work this cycle
16:27:46 <krtaylor_> #link https://etherpad.openstack.org/p/kolla-queens-doc-restructure
16:27:48 <egonzalez90> I think is good as it is now to merge
16:27:59 <krtaylor_> #link https://blueprints.launchpad.net/kolla/+spec/queens-doc-restructure
16:28:11 <krtaylor_> I also sent an email to the list last week with all this info
16:28:33 <krtaylor_> and there is a patch that includes all the ToC changes that we discussed at PTG
16:28:43 <krtaylor_> #link https://review.openstack.org/#/c/504801
16:29:02 <krtaylor_> that is looking pretty good
16:29:25 <krtaylor_> next step is to get interested folks to jump into the etherpad and put their name next to a section they'd like to rework/refresh or add a section
16:29:38 <krtaylor_> Else I'll just keep chipping away at it
16:30:06 <inc0> right, let's all help Kurt, I can't stress enough how important it is
16:30:14 <britthouser> count me in.
16:31:13 <inc0> anything else krtaylor_ ?
16:31:13 <coolsvap> +1
16:31:19 <krtaylor_> Cool! Thanks everyone - there is some good work that already exists
16:31:28 <egonzalez90> +1
16:31:37 <inc0> so few more remarks from me
16:31:59 <inc0> as soon as we get our images published to dockerhub
16:32:02 <krtaylor_> That we need to go through, but if everyone can review and get what we have closed out so we can move forward, or put all notes in etherpad
16:32:20 <krtaylor_> Anyway, thats about all I have
16:32:21 <inc0> I'll rework quickstart to skip build part at all (for kolla-ansible)
16:32:46 <krtaylor_> I haven't touched koala-ansible at all yet
16:33:09 <britthouser> makes sense.
16:33:23 <krtaylor_> kolla-ansible that is
16:33:41 <inc0> ok, can we move on?
16:33:55 <krtaylor_> Fine with me, thanks inc0
16:34:04 <inc0> #topic rabbitmq clustering crysis
16:34:13 <spsurya__> krtaylor_: for kolla-ansible https://review.openstack.org/#/c/507004/
16:34:15 <inc0> I took liberty of injecting my own topic;)
16:34:22 <inc0> so we need to fix rabbitmq
16:34:30 <inc0> it was misbehaving a lot lately
16:34:38 <inc0> and rabbitmq clusterer is deprecated upstream
16:34:53 <inc0> clustering now is part of rabbitmq core
16:35:04 <inc0> which means we should rework our rabbitmq deployment
16:35:18 <inc0> can I have volunteer to take this one?
16:35:53 <inc0> :(
16:36:36 <coolsvap> I will look into it
16:36:46 <inc0> our current state https://www.youtube.com/watch?v=tgj3nZWtOfA
16:36:53 <inc0> thanks coolsvap
16:37:36 <inc0> ok, that's it from me:)
16:37:44 <inc0> #topic open discussion
16:37:50 <krtaylor_> spsurya__, I added that to the etherpad, thanks!
16:38:04 <britthouser> I have one thing.
16:38:07 * jamesbenson run away!  ...grabs the holy grenade...
16:38:24 <inc0> shoot britthouser
16:38:49 <britthouser> I remember awhile back some teams moved their meetings into their team channel.  I wondered what folks here thought about doing that?  So we'd run this meeting in #openstack-kolla instead of #openstack-meeting-4
16:39:53 <hrw> easier to not miss or to read meeting notes from logs
16:40:06 <jamesbenson> agreed +1 from me
16:40:08 <hrw> I log all channels/queries to local hdd
16:40:21 <inc0> which teams do that now?
16:40:36 <hrw> so that way even if I was not on a meeting I can read log next day without checking where to find it
16:41:04 <krtaylor_> Does our channel have the meeting (logs) bot added?
16:41:07 <britthouser> I'd have to check @inc0.  It was months ago, when the time slots in the meeting channels were getting full.
16:41:18 <jascott1> -1 cause its not separate but +1 cause I can catch up in slack if need be
16:41:18 <inc0> please do britthouser
16:42:05 <inc0> having separate meeting room has it's merits
16:42:11 <jamesbenson> I have a qq as well.  I think last week or the week before. we talked about external ceph. I'm working on an ansible script but wondering if anyone else was doing the same?
16:42:15 <britthouser> Ok will do. Something to think about, don't have to decide today.  Just wanted to put it out there for our subconciouses to mull over.
16:42:16 <krtaylor_> I would prefer to have a meeting log, but don't care what channel it is in
16:42:19 <inc0> people wont join in the middle
16:42:20 <coolsvap> britthouser: I think one of the advantage of having official meeting channels is people are kinda subscribed to them, so if we need someone during the meeting there is more chance we will find them in official meeting channels than looking for them
16:42:46 <inc0> all meetings are logged
16:42:48 <hrw> bye
16:43:16 <coolsvap> thats one thing but I am fine with being held in openstack-kolla channel
16:43:25 <inc0> http://eavesdrop.openstack.org/meetings/kolla/
16:43:26 <spsurya__> krtaylor_: http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-4/
16:43:37 <spsurya__> you always have
16:43:41 <krtaylor_> +1 as long as we can start meeting/endmeeting etc
16:43:52 <inc0> you have this link in meeting wiki
16:44:17 <krtaylor_> Yes, as long as we'd keep that in -kolla, I'm +1
16:44:34 <inc0> I think we do
16:44:38 <inc0> anyway, that's for later
16:44:53 * britthouser yields the floor
16:45:02 <coolsvap> inc0: http://lists.openstack.org/pipermail/openstack-dev/2017-June/118899.html
16:45:03 <coolsvap> fyui
16:45:19 <coolsvap> fyi*
16:45:54 <inc0> thanks coolsvap that's helpful
16:46:16 <inc0> anyone else has anything for open discussion?
16:46:46 <jamesbenson> I think last week or the week before. we talked about external ceph. I'm working on an ansible script but wondering if anyone else was doing the same?
16:47:37 <inc0> sorry you said that before jamesbenson :(
16:47:41 <inc0> well there is ceph-ansible
16:47:43 <jamesbenson> no worries
16:47:59 <inc0> https://github.com/ceph/ceph-ansible
16:48:17 <jamesbenson> okay, I know I had issues with ceph-ansible, I thought I remember others mentioning the same.  But if we are moving that way, no problem :-)
16:48:18 <inc0> but people report mixed results'
16:48:29 <inc0> we don't know yet
16:48:40 <inc0> current plan is that we upgrade to L
16:48:44 <jamesbenson> yeah, this is an ansible ceph-deploy method, not ceph's ansible deploy
16:48:45 <inc0> so queens is L
16:49:06 <inc0> and then, before Q is released we decide to either keep ceph deployment or deprecate it
16:49:09 <jamesbenson> yeah I got L currently as external, it's very nice and ^_^
16:49:21 <inc0> if we deprecate it, removal will coincide with next LTS ceph release
16:49:30 <inc0> so M wouldn't be in Kolla any more
16:50:18 <inc0> on one hand I'd like not having ceph, on the other we need 1. easy and reliable ceph deployment mechanism
16:50:26 <inc0> 2. migration path from our current deployment
16:50:26 <jamesbenson> okay, so a few months before we figure out anything.  Are the ceph guys working with us on incorporating it at all?
16:50:43 <inc0> yes, we talked to them and we'll work together to figure it out
16:50:48 <jamesbenson> cool
16:51:03 <jamesbenson> Pike isn't going to get L at all though, correct?
16:51:11 <inc0> no
16:51:18 <inc0> well, since you use external
16:51:22 <inc0> it doesn't really matter for you
16:51:30 <jamesbenson> we do lots of deploys. ;-)
16:51:32 <inc0> but kolla-deployed pike is Jewel
16:51:44 <inc0> ok, sorry;)
16:51:56 <inc0> what I wanted to say is client-side shouldn't really matter
16:52:03 <jamesbenson> yeah
16:52:24 <jamesbenson> that's all for me then
16:52:31 <jamesbenson> just wanted that status update
16:52:35 <jamesbenson> thanks
16:52:41 <inc0> ceph, in my book, is as important as mariadb
16:52:46 <inc0> or almost as important
16:53:00 <jamesbenson> both definitely play critical roles.
16:53:04 <inc0> and I don't see us getting rid of mariadb deploy anytime soon
16:53:15 <inc0> so I wouldn't be surprised if we actually keep the ceph
16:53:31 <inc0> streamlined deployment experience is important
16:54:13 <inc0> ok, anyone else have a topic?
16:55:56 <inc0> guess not
16:55:59 <inc0> thank you all
16:56:03 <inc0> #endmeeting kolla