15:59:28 <inc0> #startmeeting kolla
15:59:29 <openstack> Meeting started Wed Jun 28 15:59:28 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:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:34 <openstack> The meeting name has been set to 'kolla'
15:59:42 <inc0> #topic w00t for Kolla!
15:59:56 <inc0> few minutes to show the love guys;)
16:00:17 <duonghq> woot
16:00:21 <sdake> o/
16:00:26 <spsurya_> w00t
16:00:27 <Jeffrey4l_> woot
16:00:30 <egonzalez> woot!
16:00:49 <sdake> resistance is futile?:)
16:00:50 <coolsvap> hello guys o/ w00t!
16:00:53 <krtaylor> o/
16:00:59 <sdake> hey coolsvap how u been
16:01:03 <inc0> welcome back coolsvap:)
16:01:14 <duonghq> hi coolsvap
16:01:22 <spsurya_> sup coolsvap
16:01:25 <rwellum> woot
16:01:28 <jascott1> w00t
16:02:08 <coolsvap> i am all well its good to be back :)
16:02:20 <mandre> woot
16:02:22 <sdake> https://vignette2.wikia.nocookie.net/uncyclopedia/images/a/ad/Drop_bear.JPG/revision/latest?cb=20050510111310&format=original
16:02:25 <mandre> oh, hi coolsvap!
16:02:36 <ttx> coolsvap is back!
16:02:56 <inc0> we're all very happy to see you Swapnil
16:03:25 <coolsvap> thanks inc0 :)
16:03:34 <inc0> ok, let's get to meeting
16:03:35 <spsurya_> sdake: +1
16:03:40 <inc0> #topic Announcements
16:04:02 <inc0> so happy day for our community, not only coolsvap is back, we also have new core member!
16:04:15 <inc0> congratulations to spsurya_ and great job!
16:04:23 <rwellum> Congrats spsurya_ !!
16:04:27 <coolsvap> spsurya_: (y)
16:04:52 <duonghq> congrats spsurya_
16:04:58 <egonzalez> congrats spsurya_
16:05:06 <inc0> any other announcements?
16:05:26 <inc0> guess not:)
16:05:31 <inc0> let's get to agenda
16:05:32 <spsurya_> thanks all for votes and wishes
16:05:47 <inc0> #topic Triaging of bugs for this week (spsurya)
16:06:01 <inc0> I took liberty of removing k8s tool from this topic as we have dedicated one next
16:06:05 <spsurya_> https://etherpad.openstack.org/p/kolla-bug-triage-week
16:06:15 <inc0> #link https://etherpad.openstack.org/p/kolla-bug-triage-week
16:06:17 <spsurya_> this got few one which are ready to fix
16:06:35 <spsurya_> if anyone like they can pick from this
16:06:44 <spsurya_> to conitrubte
16:07:39 <rwellum> What does status 'ready to fix' mean exactly? It's a triaged as a valid bug and looking for an owner?
16:07:42 <spsurya_> more interesting one
16:07:51 <spsurya_> tested rwellum tool
16:07:57 <inc0> rwellum: yeah
16:08:13 <spsurya_> rwellum: yes looking for owner
16:08:17 <inc0> spsurya_: hold that thought, we have rwellum tool topic after this one
16:08:17 <rwellum> thanks
16:08:30 <spsurya_> you can grab any if you like
16:08:38 <spsurya_> to contribute more
16:08:50 <inc0> also if anyone ever asks how to contribute
16:08:52 <spsurya_> so on rwellum tool
16:08:56 <inc0> this is great list to get people started
16:09:03 * krtaylor looks
16:09:04 <inc0> right, I'll just start the topic;)
16:09:15 <inc0> #topic Question - upstream a tool (or not)? rwellum
16:09:23 <spsurya_> Intially found some imrovement in tools and communicated the same with rwellum.
16:09:23 <spsurya_> thanks rewellum for keeping fix the monir issues.
16:09:23 <inc0> rwellum spsurya_ go ahead
16:09:42 <inc0> https://github.com/jascott1/arboreal/ I
16:09:44 <spsurya_> Successfully tested AIO on centos with 2 NICs, 16GB RAM, 50GB HDD, 4CPUs resources.
16:09:48 <inc0> I'll add this one too
16:10:00 <inc0> rwellum: mind pasting link to your rtepo please?
16:10:18 <spsurya_> inc0: IMO would be good if he push it to upstream and get some feedback more people
16:10:23 <rwellum> yes was good to get another (core) use it - before sending to everyone.
16:10:24 <rwellum> https://github.com/RichWellum/k8s
16:10:54 <spsurya_> Failed with 1CPUS as well as with 2 CPUs that should not happen.
16:10:54 <spsurya_> This may be the issue in kubernetes 1.6.5
16:11:10 <spsurya_> as per rwellum IIRC
16:11:20 <inc0> so let's discuss what we want to do in general
16:11:26 <inc0> with this problem
16:11:54 <spsurya_> inc0: Need to test on Ubuntu 16.04 too which is left AIO
16:11:58 <inc0> we have Arboreal that sets up k8s with terraform+ansible
16:12:20 <inc0> we also have playbook for kolla there
16:12:32 <inc0> we have rwellum's tool
16:12:33 <jascott1> the terraform bits need a little more work but I am doing that now
16:12:46 <jascott1> imean they work but arent as portable as could be
16:12:49 <inc0> apperantly there is need for that stuff:)
16:12:58 <spsurya_> jascott1:
16:13:08 <spsurya_> rwellum: tool also need some work
16:13:19 <spsurya_> to get into final shape
16:14:24 <sdake> i'd recommend focusing on one deployment mechanism rather than 3 parallel development paths :)
16:14:34 <inc0> that too
16:14:54 <sdake> i'm personally a fan of the microchart ansible approach - very flexible and complete control
16:14:55 <inc0> but since we have at least 2 different
16:14:58 <inc0> problem is real
16:15:05 <rwellum> Yeah that's why I raised it in the first place as an agenda item.
16:15:28 <rwellum> Don't want to deflect potential users and contributors from jascott1 excellent solution.
16:15:41 <spsurya_> sdake: +1, yes we need one deployment mechanism
16:15:53 <rwellum> I was mainly through developing this tool when I saw jascott1 was doing this.
16:16:01 <sdake> simple is good - i believe brad's approach is pretty solid - haven't looked at your solution jascott1
16:16:12 <jascott1> its the dev guide in ansible format
16:16:19 <inc0> rwellum: neither are excellent, but I agree with sdake, we need good and easy method to move from clean k8s to kolla
16:17:05 <sdake> jascott1 there were some earlly reviews on brad's approach - and there was some desire to keep things "seprated"
16:17:39 <inc0> sdake: separated will be super easy when we have roles figured out
16:17:55 <rwellum> I haven't seen 'Brads' tool sdake - I know there is also a shell-script - I thought that was the second tool.
16:18:02 <sdake> what i'm saying in essence is jascott1 bradjones can you guys team up plz :)
16:18:03 <inc0> #link https://review.openstack.org/#/c/473588/8
16:18:10 <jascott1> at least between the two approaches we should have all/most of the functionality we need and be able to reference each
16:18:25 <inc0> I'll also add this
16:18:29 <inc0> #link https://review.openstack.org/#/c/474770/
16:18:38 <inc0> at some point we'll run Brad's playbook from inside container
16:18:44 <inc0> and this might be the container
16:19:37 <inc0> we can create helm chart to run playbooks:)
16:19:55 <inc0> helm install orchestration/generate-config
16:20:02 <rwellum> So these ansible approaches seem almost like they are heading towards production level usage? My tool is a simple single user, AIO on a VM. Good for learning k8s and kolla etc.
16:20:02 <inc0> helm install orchestration/deploy-kolla
16:20:04 <sdake> i like it  -based upon kfox1111 's review of brad's work - the config gen should be a seprate thing i htink
16:20:19 <sdake> rwellum yes - these are production deployment tools
16:20:28 <sdake> (or will be ;)
16:20:33 <inc0> I kinda disagree, it has to be optional
16:20:42 <inc0> but in kolla-ansible config gen is part of deployment
16:20:44 <inc0> and I like that
16:20:52 <inc0> if you want to provide your own configs, fine
16:21:15 <sdake> here is what i'd recommend with the approach to solving this problem
16:21:27 <sdake> we know for certain deployment is one type of "playbook" needed
16:21:35 <sdake> lets get that working well in a docker container launched by a helm install
16:21:46 <sdake> and then sort out the next part fo the solution next
16:21:49 <inc0> that's what I propose...
16:21:57 <inc0> and that's what this change is about..
16:22:00 <sdake> if we try to solve too many porblems at once, we end with sea salt production
16:23:27 <inc0> what I'm trying to say
16:23:36 <inc0> is when we have docker image with ansible in it
16:23:39 <inc0> we can do all
16:23:49 <sdake> right makes sense
16:25:14 <inc0> kfox1111 around?
16:26:17 <inc0> ok, I guess we need to get kfox1111 and Serguey on board
16:26:33 <inc0> let's talk to them later today about that
16:26:53 <inc0> in the meantime, I'll work on dockerfile part + configmap generation, that's coming on nicely
16:27:04 <inc0> and Brad's playbook should be easy afterwards
16:27:27 <inc0> to be put into container that is
16:28:09 <inc0> anything else on the topic?
16:28:38 <inc0> guess not
16:28:45 <inc0> #topic Open discussion
16:28:52 <inc0> one thing from me
16:28:55 <rwellum> I guess with both ansible solutions floating around, the general consensus is my tool is probably not upstream-worthy at this point. So occasionally we have new folks on IRC struggling to bring up kolla-k8s. Like 'ddejog'. I should point him to jascott1 solution then?
16:29:15 <rwellum> Sorry inc0  - slow typer here
16:29:22 <sdake> rwellum you can push a review - and then people can use it
16:29:24 <inc0> rwellum: feel free to suggest your own tool, no worries about that
16:29:39 <rwellum> Oh ok then.
16:29:42 <inc0> what we're sayin is it's a prothesis and we need something better which is in the making by Brad and myself
16:29:44 <sdake> i think we have decided to boil this sepcific ocean with ansible however :)
16:29:48 <rwellum> Cheers guys.
16:29:54 <rwellum> Yes agree fully with that.
16:30:10 <inc0> so let's focus on proper way to solve it is what we're saying;)
16:30:46 <inc0> from me, I need these changes merged for docker registry people;) https://review.openstack.org/#/c/475940/ https://review.openstack.org/#/c/475940/
16:30:59 <inc0> https://review.openstack.org/#/c/475469/
16:31:33 <inc0> infra change is blocked on these 2 and whole dockerhub publisher is blocked on this
16:31:43 <inc0> so can I have some reviews please?:)
16:32:02 <rwellum> Two of those links are the same inc0 ?
16:32:19 <inc0> https://review.openstack.org/#/c/475940/ https://review.openstack.org/#/c/475469/
16:32:21 <inc0> these two
16:33:01 <rwellum> ok
16:33:33 <rwellum> Will take a look.
16:34:00 <inc0> thank you
16:34:08 <inc0> anything else wants to say anything?
16:34:12 <inc0> anyone*
16:34:15 <duonghq> o/
16:34:20 <inc0> go ahead Duong
16:34:55 <duonghq> on slim image effort, I saw this: https://dzone.com/articles/minideb-a-minimalist-debian-based-docker-image
16:35:12 <duonghq> I think we can grab the idea which is clean up image after install anything?
16:35:28 <inc0> duonghq: impossible if you have layers
16:35:36 <duonghq> in general: we can have some script to wrapper thing like this
16:35:41 <inc0> then you will just double cleanup size really
16:35:54 <inc0> that'd be great when docker --squash is a thing
16:36:21 <duonghq> hmm, another idea: will we use slim image like alpine?
16:36:40 <inc0> package availability becomes issue
16:36:45 <coolsvap> I think that was brought earlier as well
16:36:53 <coolsvap> agree with inc0
16:37:04 <inc0> that being said, this creates wrapper around apt-get install it seems
16:37:11 <inc0> so you install and cleanup in same layer
16:37:20 <duonghq> yeah
16:37:21 <inc0> which is cool, but might be longer
16:37:39 <duonghq> but I think it's worth if we can slim down the image
16:38:14 <inc0> yeah, depends on priorities I guess, but definetly worth to try
16:38:22 <duonghq> ya
16:38:44 <inc0> duonghq: wanna try to do it? I think it should be as easy as changing macro install packages and using base distro debian
16:39:03 <duonghq> I think I'll give it a try
16:39:26 <inc0> cool, thanks
16:39:41 <inc0> cutting megs from our images is always good
16:39:49 <duonghq> sure
16:39:58 <inc0> after docker squash works we can get even better at it
16:40:11 <duonghq> I'm waiting for it
16:40:27 <inc0> great idea, thanks
16:40:45 <inc0> another thing - with fresh images in dockerhub time of build becomes less of a factor
16:40:54 <inc0> size become more
16:41:13 <inc0> so if we can get slow building small images, as long as we build->upload them nightly
16:41:15 <inc0> it's cool
16:41:59 <inc0> so, anything else?
16:42:07 <duonghq> from me: no
16:42:18 <inc0> anyone?
16:42:59 <inc0> ok, I think we can wrap it up:)
16:43:03 <inc0> thank you all for coming!
16:43:07 <inc0> #endmeeting kolla