16:32:07 <sdake> #startmeeting kolla
16:32:08 <openstack> Meeting started Wed Jan  6 16:32:07 2016 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:32:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:32:11 <openstack> The meeting name has been set to 'kolla'
16:32:12 <sdake> #topic rollcall
16:32:14 <SamYaple> o/
16:32:15 <britthouser> 0/
16:32:20 <Jeffrey4l> o/
16:32:21 <nihilifer> hello
16:32:21 <rhallisey> hi
16:32:22 <elemoine> o/
16:32:25 <sdake> morning folks \o/ :)
16:32:35 <akwasnie> hi
16:32:41 <Jeffrey4l> sdake, mornings
16:32:48 <stvnoyes> hi
16:33:03 <akwasnie> "Next meeting scheduled for January 6th, 1600 UTC" -> was afraid i missed the meeting
16:33:11 <SamYaple> akwasnie: i fixed that :P
16:33:22 <akwasnie> ;)
16:33:25 <sdake> woops ;)
16:33:30 <jpeeler> hi
16:33:40 <ajafo> hi
16:33:44 <sdake> ok well we have a mountain of poeple
16:33:55 <sdake> so I will just  get started :)
16:33:56 <sdake> #topic announcements
16:34:35 <sdake> 1. milestone 1 was tagged.  I asked Sam Yaple to serve as backup in the case I am unable to tag the milestones.  Thanks for testing this first tag sam!
16:35:33 <sdake> 2. the midcycle is february 9th and february 10th, Tuesday/Wednesday.  Breakfast + lunch + coffee + soda are provided both days, dinner is provided Tuesday
16:35:42 <sdake> so the food costs should be minimal to zero
16:35:56 <sdake> reallly the midcycle expense will be flight and hotel
16:36:10 <sdake> I am going to set up an invitation thing so I can see who is coming
16:36:17 <sdake> anyone is free to come if they like
16:37:05 <sdake> I think I had one more announcement but it escapes me atm
16:37:14 <sdake> does anyone from the community have any announcements?
16:37:37 <SamYaple> I have a new project bringing backups to openstack called ekko! #openstack-ekko
16:37:41 <SamYaple> you didnt say kolla specific :P
16:37:48 <sdake> lol
16:37:55 <sdake> yes kolla specific please ;)
16:38:16 <sdake> #topic midcycle planning
16:38:48 <sdake> We spent about 15 minutes in our lsat meeting before the end of 2015 proposing an agenda for the midcycle
16:39:05 <sdake> I'd like to finish the job on that today - with a 10-15 minute timer
16:39:14 <sdake> does anyone have the link handy of our last midcycle work?
16:39:43 <britthouser> https://etherpad.openstack.org/p/kolla-mitaka-midcycle
16:40:28 <sdake> thanks britt
16:40:37 <sdake> #link https://etherpad.openstack.org/p/kolla-mitaka-midcycle
16:40:55 <sdake> plese open that up and lets spend until 55 on the clock workign on it
16:41:24 <britthouser> samyaple and I need to armwrestle for that color. =P
16:41:25 <sdake> please feel free to add your name so I know which color represents which author :)
16:47:42 <SamYaple> britthouser: lol
16:49:27 <akwasnie> https://wiki.openstack.org/wiki/Sprints -> maybe we should add kolla to the list?
16:53:18 <sdake> ok think time is up
16:53:25 <sdake> akwasnie I will take care of the sprints page
16:53:33 <sdake> I was gathering info yesterday and sorting out logistics
16:53:36 <sdake> they are all sorted otu now
16:53:43 <sdake> (and obtaining budget for various things)
16:53:57 <akwasnie> sdake: ok :)
16:54:17 <sdake> next on agenda
16:54:25 <sdake> #topic kolla-mesos TLDR update
16:54:40 <sdake> nihilifer your up :)
16:55:14 <nihilifer> this week we were mainly focused on getting unlocked from images @ dockerhub
16:55:19 <nihilifer> so i made our own
16:55:34 <nihilifer> + used ansible for they deployment
16:55:56 <sdake> which type of images?
16:56:04 <nihilifer> docker images
16:56:14 <nihilifer> for zk, mesos(slave/master), marathon, chronos
16:56:15 <sdake> containing what applciations?
16:56:17 <sdake> ok got it
16:56:31 <sdake> you don't want to use the upstream provided ones because they are deficient in some way?
16:56:42 <nihilifer> they're
16:56:43 <harmw> nihilifer: based on centos/ubuntu?
16:56:46 <nihilifer> 1) not up to date
16:56:58 <nihilifer> 2) they run all things as root
16:57:33 <sdake> ok well makes sense to me
16:57:41 <sdake> plus no wwe can make them for all the variou distros ;-)
16:57:44 <nihilifer> harmw: the ones i pushed to kolla are for both centos and ubuntu
16:58:01 <nihilifer> this stuff i'm mentioning is in review now
16:58:05 <sdake> any other updates or shall I move on?
16:58:30 <harmw> are all required tasks in this area in LP?
16:58:32 <nihilifer> after getting that merged i think we may focus on bringing the other os services
16:58:36 <sdake> nihilifer fwiw  Ithink it makes sense for us to provide  docker images for any software we expect to run in a kolla environment
16:58:40 <nihilifer> that's all from me :)
16:58:51 <harmw> yes sdake, indeed
16:58:59 <sdake> #topic elk containers - official images vs our own dockerfiles
16:59:10 <sdake> which leads us to -> :)
16:59:21 <akwasnie> with transition from docker to kolla_docker an issue appeared
16:59:22 <britthouser> official = rhel atomic ones? or something else?
16:59:42 <akwasnie> for example, to deploy ELK services we use official images from dockerhub, which require additional param to be specified using ansible command
16:59:44 <sdake> official are thte upstream provided iamges of elkstack pre-configured
17:00:02 <SamYaple> to bring the contaienrs in line with kolla images we really need to build our own (for things like COPY_ONCE and the like)
17:00:14 <harmw> ^^ yep
17:00:18 <britthouser> ok, I wasn't aware of those, only that RH now provides some as part of atomic.  They might be the same thing though
17:00:58 <akwasnie> ansible command is not available in kolla_docker, which force us to decide if we want to drop official images in favor of possibility of using configuration file (mechanism provided in kolla base image)
17:01:40 <inc0> or we could implement it into kolla_docker
17:01:44 <inc0> how hard is it?
17:01:44 <SamYaple> akwasnie: adding the 'command' thing is no problem
17:01:51 <SamYaple> but do we want to is teh question
17:01:59 <harmw> can we tell official images which config file to load? if not, we should build our own
17:02:04 <SamYaple> i want to keep our images in line with all the other structure (config.json COPY_ONCE etc)
17:02:13 <sdake> i am in favor of using our own images for all kolla-specific things
17:02:24 <akwasnie> harmw: we can, but only using command,
17:02:25 <sdake> so the quesetion is, is anyone NOT in favor of using our own images?
17:02:44 <sdake> if someone is not in favor, then we need to see if that is a majority or not
17:02:49 <pbourke_> +1 for using our own
17:03:03 <sdake> because as stands now, we will be proceeding with our own images
17:03:11 <Jeffrey4l> +1 for using ours.
17:03:14 <sdake> but we rule by majority ;)
17:03:21 <pbourke_> the dockerhub ones strike me as more general purpose, it seems common enough to craft customs
17:03:26 <britthouser> Yeah our own makes sense. maybe we should have a test to use of when we'll use our own vs use others.
17:03:30 <harmw> +1 (I can even help in this area, yay)
17:03:36 <SamYaple> +1
17:03:43 <akwasnie> +1 :)
17:03:51 <nihilifer> +1
17:04:17 <rhallisey> seems fine with me though I don't quite understand what 'our images' are
17:04:36 <akwasnie> rhallisey, own dockerfiles
17:04:42 <harmw> images Kolla depends on/uses
17:04:45 <harmw> ?
17:04:53 <elemoine> I guess extending kolla_docker when needeed makes sense too
17:04:55 <rhallisey> well what is changing then?
17:05:25 <akwasnie> for example we use logstash official image from dockerhub, and if we want to drop official ones we have to create own configuration in dockerfiles
17:05:25 <pbourke_> rhallisey: not much, but they follow our conventions
17:05:32 <sdake> rhallisey  we were in the past trying to use standard elkstack provided images for docker things
17:05:52 <sdake> now we are not ogin to do that, we are going to roll our own that fit our API for start extension, config, etc
17:05:53 <rhallisey> oh I get it
17:06:08 <rhallisey> kk cool
17:06:13 <inc0> more work but we have control over it
17:06:28 <SamYaple> more uniform too. less code to know and understand
17:06:31 <inc0> we won't run into same type of problems as we ran into with ansible+docker
17:06:37 <SamYaple> on the deploy side that is
17:06:37 <sdake> inc0 frankly I think our team is of the size we can handle the work
17:07:05 <inc0> yeah, I think we can use dockerfiles from dockerhub as reference
17:07:24 <inc0> which means it will be even easier
17:07:26 <jpeeler> exactly ^
17:07:34 <jpeeler> i don't see this as big deal
17:07:35 <harmw> I have containers for EFK already :)
17:07:46 <akwasnie> i can do it as a part of my work in ELKs blueprint
17:07:47 <harmw> so adding in Kolla stuff should be fairly easy
17:07:55 <sdake> #topic log processing engine bssed on Hek
17:08:06 <sdake> elemoine I am not familiar with Hek, can you give us a quick overview?
17:08:13 <sdake> keep in mind we have about 12 minutes for this opic
17:08:14 <sdake> topic
17:08:20 <elemoine> let me introduce myself first
17:08:35 <elemoine> my name is Eric Lemoine, I work for Mirantis
17:08:46 <elemoine> as a developer in the logging/monitoring team
17:09:13 <elemoine> I've joined Mirantis 2 months ago, and I've been following Kolla since then (and I like it :)
17:09:15 <SamYaple> Hi Eric
17:09:26 <elemoine> so
17:09:26 <rhallisey> hi
17:09:32 <sdake> welcome aboard ;-)
17:09:36 <pbourke_> o/
17:09:37 <elemoine> thanks
17:09:46 <harmw> hi
17:09:49 <akwasnie> hi
17:09:59 <elemoine> I just wanted to mention here that we (my team) are considering working on a blue print for Kolla
17:10:21 <elemoine> proposing a scalable log processing solution based on Heka
17:10:33 <elemoine> this will build on the ELK work we just discussed
17:10:48 <SamYaple> since we have no solution for log processing, i think anything you propose that you will work on (that works) will be fine with us elemoine
17:10:55 <sdake> so not supplant elk, but be in addition to?
17:11:14 <elemoine> the blueprint will include more information, but I just wanted to know if people agreed with the general intent
17:11:33 <harmw> where exactly does it fit in the ELK picture?
17:11:36 <elemoine> sdake, good question
17:11:45 <sdake> what is Heka
17:11:47 <inc0> elemoine, whats hek?
17:11:53 <inc0> heka
17:11:54 <elemoine> we also use Elasticsearch and Kibana
17:12:07 <elemoine> but use Heka instead of Logstash
17:12:19 <inc0> how Heka is better than Logstash?
17:12:27 <inc0> what are differences?
17:12:30 <nihilifer> it's written in go :P
17:12:35 <harmw> I use fluentd, so wondering the same as inc0 here :)
17:12:36 <elemoine> and the architecture we want to propose is a bit different that the one based on Logstash
17:12:48 <akwasnie> so basically you want to ELK -> EHK ?
17:12:56 <inc0> akwasnie, yeah
17:13:09 <elemoine> we think Heka is lightweight and can run on every node, for a distributed architecture that scales
17:13:12 <sdake> sounds like a topic for midcycle discussion I think
17:13:12 <inc0> so I'm not philosophically bound to logstash
17:13:31 <elemoine> cool, that's what I wanted to know
17:13:38 <inc0> we just threw a name, I don't think anyone else is, so it might be good to consider heka underneath
17:13:46 <inc0> I would be -1 on having both
17:13:47 <sdake> unfortunately midcycle is 1 month out
17:13:47 <elemoine> I could provide more details, but this is what the blueprint will be about
17:14:05 <sdake> elemoine a mailing list mail would be good or ya a detailed blueprint
17:14:18 <harmw> I'm interested in this elemoine, please inform us with the BP :)
17:14:20 <inc0> elemoine, so could you please provide good comparason between these two so we could decide on better one?
17:14:23 <elemoine> I already started on the blueprint doc
17:14:25 <sdake> as in why this logstash repacement is necessary
17:14:43 <elemoine> it should be ready soon
17:14:47 <britthouser> does heka exist already, and we just want to integrated in Kolla, or heka is what you are writing?
17:14:54 <sdake> what I dont wan tto do is introuce a bunch of chnge in our plan here for no good reason :)
17:14:54 <harmw> and which crap in logstash it tries to fix
17:15:01 <elemoine> the doc will discuss Heka vs Logstash and why we use and want to propose Heka
17:15:12 <harmw> +1
17:15:26 <sdake> who writes heka - mirantis?
17:15:27 <inc0> also talk with akwasnie as she did fair amount of work on integrating logstash
17:15:37 <elemoine> Heka is maintained by Mozilla
17:16:01 <sdake> cool
17:16:02 <elemoine> yes, I obviously want to talk to akwasnie about it
17:16:14 <sdake> well lets get an A/B comparison of Heka vs logstash on the mailing list as a fist step
17:16:15 <akwasnie> sure, will help
17:16:21 <akwasnie> if you want :)
17:16:29 <sdake> #action elemoine to post A/B comparison of Heka vs Logstash on the mailing list
17:16:31 <elemoine> sure I'll write to the mailing list
17:16:31 <SamYaple> all i know is there can be only one!
17:16:45 <sdake> yes, we need one, so lets make the best choice
17:16:45 <elemoine> ok, clear on that, and I agree with you
17:17:07 <elemoine> what's important is the architecture we want to propose (for scaling)
17:17:29 <elemoine> we think that Logstash is a major bottleneck in the current architecture
17:17:46 <sdake> more theoretical scaling work
17:17:47 * sdake groans
17:17:52 <elemoine> so it's not only about the software
17:17:54 <harmw> logstash has issues, yes
17:18:07 <elemoine> it's about the architecture
17:18:13 <elemoine> a diagram will help
17:18:17 <elemoine> :)
17:18:25 <sdake> ok well lets start small with an A/B comparsion of logstash vs heka
17:18:27 <sdake> before diving in to the architecture
17:18:36 <sdake> you can follow up the on the ml with an architecture proposal chagne ifyou want :)
17:18:43 <elemoine> hmm both are a bit mixed
17:18:47 <elemoine> but ok
17:18:52 <SamYaple> well do it the best we can
17:18:59 <elemoine> cool
17:19:02 <sdake> ok well do whatever yo ucan to get the information shared
17:19:10 <sdake> but lets do it on the mailing list at first pelase
17:19:19 <elemoine> that's all for me, I just wanted to let you know about my intent
17:19:24 <elemoine> sdake, sure
17:19:29 <sdake> cool welcome to the party :)
17:19:35 <elemoine> thx again
17:19:43 <sdake> #topic open discussion
17:19:45 <sdake> first up is me :)
17:19:57 <sdake> the midcycle will include invitations for the regular event as well as dinner
17:20:07 <sdake> please RSVP for dinner so I can get an accurate count
17:20:11 <sdake> dinner is hosted by Cisco
17:20:15 <SamYaple> RSVP
17:20:25 <sdake> lunch + the regular midcycle are hosted by Servosity
17:20:31 <sdake> breakfast is hosted by your PTL :)
17:20:45 <sdake> we are having bruegers bagels - yay :)
17:20:55 <SamYaple> there is coffee outside the office
17:21:00 <sdake> ok that is all, please rsvp
17:21:13 <SamYaple> i have one thing
17:21:14 <britthouser> there will be a link for RSVP?
17:21:15 <sdake> cool well this comes with bagels and stuff
17:21:18 <britthouser> I didn't miss it did I?
17:21:25 <sdake> britthouser  yes its coming
17:21:27 <sdake> before week is out
17:21:35 <sdake> i was workig non budget + logistics
17:21:59 <sdake> organizign a midcycle is harder then it looks ;)
17:22:02 <britthouser> ok I'll watch for link
17:22:04 <britthouser> =)
17:22:25 <SamYaple> Ok. so we now have pull playbooks
17:22:25 <pbourke_> were upgrades brought up today?
17:22:29 <SamYaple> pbourke_: yes
17:22:35 <pbourke_> ok I'll check logs
17:22:41 <sdake> sam is up first, pbourke up second
17:22:48 <sdake> 8 minutes guys share the time please :)
17:22:56 <SamYaple> with the pull playbooks you can prestage all the images. `kolla-ansible pull` instead of `kolla-ansible deploy`
17:23:05 <pbourke_> that is nice
17:23:15 <SamYaple> that means you can test true multinode deploy time without the registry being a factor
17:23:25 <sdake> cool and that preloads the docker images?
17:23:28 <SamYaple> only two reviews on this left, https://review.openstack.org/#/c/263861/ and https://review.openstack.org/#/c/263863/
17:23:31 <SamYaple> sdake: yes
17:23:34 <sdake> fantastic
17:23:40 <sdake> SamYaple  i will review now
17:23:46 <SamYaple> i image it will also be useful during upgrade, prestage upgrade images
17:23:48 <sdake> that soundss like a killer feature
17:23:53 <SamYaple> that way down time is just a restart away
17:23:57 <sdake> ye sthis will bbe huge for upgrades
17:24:08 <SamYaple> anyway that was my thing, so everyone is aware
17:24:28 <sdake> so its kolla-ansible-pull - is it integrated with our shell tool?
17:24:35 <SamYaple> sdake: it is
17:24:38 <sdake> nice
17:24:43 <SamYaple> instead of deploy do pull
17:24:45 <sdake> that code is a bit long in the tooth :)
17:24:47 <inc0> upgrades message: plese review and test: end of message
17:24:55 <SamYaple> (if you do it know it will break kinda before you merge those patches
17:25:01 <SamYaple> )
17:25:17 <sdake> pbourke_  your up
17:25:20 <SamYaple> anyway that was my thing
17:25:43 <pbourke_> I just wanted to check what the status was on upgrades from inc0 but I think he pretty much summed it up!
17:25:53 <pbourke_> inc0: do we just have keystone right now?
17:25:58 <inc0> pbourke_, close
17:26:00 <sdake> inc0 can you give us a 3-4 minute tldr on upgrade status
17:26:02 <SamYaple> pbourke_: keystone and nova POC
17:26:03 <inc0> we had till we moved to kolla_docker
17:26:04 <sdake> I am also very interested
17:26:17 <inc0> we need to rebase it, but that should be simple enough
17:26:21 <inc0> we have nova up as well
17:26:24 <SamYaple> inc0: ill do that real quick
17:26:28 <inc0> with general logic
17:26:42 <sdake> inc0 3 minutes for state of ugprade please :)
17:26:47 <inc0> but we changed few things in keystone and nova will have to follow
17:26:49 <sdake> should have been in regular agenda - my apologies
17:27:00 <inc0> so important thing is to get keystone merged asap
17:27:12 <inc0> so we'll have solid schema for rest of plays
17:27:15 <pbourke_> i'll try give that a burn tomorrow
17:27:18 <sdake> inc0 after meting post links for review in #kolla
17:27:19 <inc0> and we can proceed with other projects
17:27:23 <inc0> ok
17:27:32 <inc0> and my request
17:27:37 <sdake> so the status is your just getting started with keystone?
17:27:41 <inc0> I don't think I'll handle every project myself
17:27:53 <inc0> so if anyone feel like helping, I'll gladly accept
17:27:55 <sdake> inc0 we wil ldistribute this like the drop root thing
17:28:10 <sdake> lets sycn up after the meeting  to get the blueprint into the right shape and i'll post a call for help
17:28:13 <nihilifer> maybe by working items on blueprint?
17:28:15 <inc0> we have bps per service up thanks to rhallisey
17:28:21 <inc0> so feel free to take on it
17:28:24 <nihilifer> ah, ok
17:28:30 <sdake> i think we need owkring items for this
17:28:33 <sdake> and close out the blueprints
17:28:40 <inc0> just, let's first merge keystone
17:28:48 <inc0> so everyone will have base to follow
17:28:55 <sdake> inc0 lets sycn up after the meeting and figure out best way to get the work distributed
17:28:57 <sdake> inc0 agreed
17:29:06 <inc0> ok, thanks
17:29:11 <inc0> that's it from me
17:29:15 <pbourke_> cheers inc0
17:29:16 <inc0> I'll post links
17:29:17 <sdake> our new way of distributing work is work items - it worked well for drop root
17:29:25 <sdake> and kept all hte info in one place
17:29:31 * nihilifer took neutron ;)
17:29:46 <SamYaple> ok upgrade keystone rebased take a look at https://review.openstack.org/#/c/257568
17:29:54 <sdake> ok times out
17:29:57 <sdake> thanks for coming folks
17:30:05 <inc0> cyas
17:30:07 <sdake> big turnout ;) _ hopefully we see this many folks at the midcycle
17:30:09 <rhallisey> bye
17:30:10 <pbourke_> so long
17:30:10 <akwasnie> thanks bye
17:30:11 <elemoine> thanks, talk next week
17:30:14 <nihilifer> bye
17:30:17 <SamYaple> byw
17:30:17 <Jeffrey4l> bye
17:30:20 <ajafo> bye
17:30:32 <sdake> #endmeeting