16:00:52 <sdake> #startmeeting kolla
16:00:52 <openstack> Meeting started Wed May 27 16:00:52 2015 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:56 <openstack> The meeting name has been set to 'kolla'
16:01:14 <sdake> #topic rollcall
16:01:23 <rhallisey> hi
16:01:33 <SamYaple> hello
16:01:42 <akwasnie> Hi
16:01:44 <sdake> o/ folks
16:01:45 <mstachow> hi all :D
16:01:50 <jpeeler> hi
16:02:13 <daneyon_> hey
16:02:19 <sdake> yo daneyon_
16:02:22 <sdake> wondering where you been bro :)
16:02:34 <sdake> grats on 10 years at csco :)
16:02:40 <daneyon_> thx
16:02:47 <sdake> #topic announcements
16:02:54 <rhallisey> daneyon_, nice!
16:03:00 <sdake> first off summit was fantastic for containers
16:03:31 <sdake> we gave a 40 minute talk on kolla
16:03:44 <sdake> which I htink overall went pretty well and gave the audience an understanding of what we are working on
16:03:48 <daneyon_> i thought i was at DockerCon then realized it was an openstack conference
16:03:50 <sdake> it didn't answer what we are working towards :)
16:03:50 <daneyon_> lol!!!!
16:04:01 <sdake> roflcopter danyeon ;)
16:04:20 <sdake> so ya, rockin job at the summit folks
16:04:23 <rhallisey> :D
16:04:33 <sdake> our irc channel members have doubled
16:04:40 <sdake> thats a sign that people really care ;)
16:04:46 <sdake> ok on with the meeting
16:04:53 <sdake> #topic l1 blueprint review
16:05:08 <sdake> liberty 1 deadline is June 25th
16:05:29 <sdake> unlike previous releases of kolla, where we were kind of loose with the release schedule I want to be strict this time around
16:05:47 <sdake> any objections from the core team?
16:05:58 <rhallisey> nada
16:06:17 <daneyon_> nope
16:06:33 <jpeeler> sounds good
16:06:50 <jpeeler> probably need to start filing more bugs into launchpad too
16:06:56 <jpeeler> and referencing them from the commit
16:07:12 <sdake> ya, we really need to stop slacking on the blueprint filing
16:07:31 <sdake> we agreed a couple weeks ago to -1 reviews that don't reference a bug or blueprint
16:07:45 <sdake> but we agreed to wait until after summit
16:07:52 <sdake> so now is the time to put that agreement into affect
16:08:02 <sdake> any objections to -1 a review without a blueprint or bug attached?
16:08:08 <daneyon_> nope
16:08:33 <sdake> the reason we file blueprints and bugs is because all that stuff gets dashboarded
16:09:01 <sdake> so for the younger cats in the crowd a dashboard is how the check writers determine where to write the checks :)
16:09:05 <sdake> stackalytics is a dashboard
16:09:20 <sdake> stats matter to some people, so its better if our stats are accurate
16:09:24 <sdake> please don't try to game the stats
16:09:34 <sdake> but lets be accurate
16:09:46 <sdake> plus it makes my life a whole lot easier determining what is in a release :)
16:09:51 <sdake> #link https://launchpad.net/kolla/+milestone/l1
16:10:01 <sdake> here is what is on deck for June 25th
16:10:05 <sdake> please take a moment to review
16:10:38 <sdake> if there is something in that list that isn't going to happen for l1, please let me know now or prior to next meeting
16:10:49 <sdake> i'll give it a few minutes for folks to look it over
16:12:04 <rhallisey> sdake, I might add something..
16:12:18 <sdake> rhallisey we are free to add right up until the 24th of june :)
16:12:40 <SamYaple> if we need blueprints or bugs to commit now, then ill be adding as well
16:12:47 <rhallisey> I'll add my min-env stuff there too
16:13:06 <sdake> if you want to add something and you are not on the drivers team, please contact a someone on the drivers team to handle assigning the blueprint or bug to you and getting it in the l1 release
16:13:19 <sdake> (i.e. your a new contributor)
16:13:35 <sdake> samyaple cool works for me
16:13:46 <sdake> try to be accurage with what you want to take on in l1
16:14:01 <sdake> fang has 4 blueprints, I think he may end up dropping some of those to l2
16:14:12 <inc0__> sdake, I'm thinking of putting pacemaker/corosynk for later and start from keepalived
16:14:18 <inc0__> corosync*
16:14:31 <sdake> inc0__ ok did you want me to make that change now?
16:14:39 <inc0__> I'll do that
16:14:41 <sdake> ok
16:14:46 <sdake> thanks :)
16:14:53 <sdake> I can use all the help anyone can offer managing the launchpad tracker
16:15:01 * sdake tired of clikcy clicky
16:15:10 <sdake> ok thats about it for l1
16:15:20 <sdake> #topic kolla manifesto
16:15:45 <sdake> #link https://etherpad.openstack.org/p/kolla-manifesto
16:15:55 <sdake> this is a 10 minute collborative editing session of our mission
16:16:07 <sdake> alot of folks had questions at summit about exactly what we do
16:16:17 <sdake> we all have opinions
16:16:21 <sdake> lets get em out there
16:16:31 <sdake> a good manifesto should not be a phd dissertation
16:16:32 <sdake> 1-2 liner
16:19:52 <sdake> nobody has put in "we do deployment"
16:20:05 <sdake> I'd like to have a discussion about that
16:20:22 <SamYaple> i dont agree that it should be a requirement
16:20:40 <SamYaple> i think rhallisey has what i see down
16:20:53 <SamYaple> flexible containers to be consumed by deployment tools
16:20:54 <sdake> samyaple huh?
16:21:19 <sdake> well we have already agreed unanmously previously deployment would be optioanl
16:21:34 <SamYaple> ah ok then
16:21:34 <sdake> shouldn't it be part of our manifesto?
16:22:13 <SamYaple> "consumed by advanced orchestration tools"? that seems like it
16:22:48 <sdake> i like line 3 and line 5
16:22:59 <sdake> perhaps we should merge those into one statement
16:23:01 <sdake> any thoughts on that?
16:23:34 <SamYaple> i agree with both.
16:24:06 <jpeeler> yep
16:24:35 <sdake> line 3 look solid?
16:24:49 <SamYaple> I dont see security mentioned. i always held that up high
16:24:57 <SamYaple> limiting perms where possible
16:25:06 <sdake> best practices?
16:25:07 <SamYaple> would that be "best practices"?
16:25:10 <sdake> we can define best practices
16:25:11 <SamYaple> ok yea
16:25:20 <rhallisey> I like it
16:25:31 <sdake> ok i'm deleting 4+
16:25:33 <daneyon_> i like it
16:25:35 <sdake> everyone godo with that?
16:25:40 <daneyon_> ya
16:25:43 <SamYaple> yes
16:25:48 <jpeeler> +1
16:26:02 <sdake> befoe we decide on this manifesto, I want to have our 2200 meeting to get input from the other folks (mostly mandre) who can't make this timeslot
16:26:31 <jpeeler> where is this text going to officially end up living?
16:26:39 <sdake> on our wiki
16:26:42 <sdake> which we dont have :)
16:26:46 <sdake> we need a wiki apge
16:26:50 <sdake> every project has a wiki page
16:27:03 <sdake> anyone want to tackle that?
16:27:31 <sdake> ok i'll add to my long list :)
16:27:53 <sdake> #topic openstack namespace
16:28:01 <sdake> atm we are in the stackforge namespace
16:28:17 <sdake> there are not really many written rules about what it takes to get into the openstack namespace
16:28:24 <sdake> but I've done it personally with 2 projects
16:28:31 <sdake> so I know what it takes
16:28:45 <sdake> I am certain we can get there this cycle
16:29:15 <sdake> when we are ready, i'm going to propose us for the openstack namespace
16:29:27 <SamYaple> what defines ready
16:29:31 <sdake> we will have a vote on it prior to the git submission to the governance repo
16:29:35 <sdake> samyaple its magic :)
16:29:40 <SamYaple> :D
16:29:46 <jpeeler> SamYaple: it just feels right
16:29:53 <sdake> jpeeler got it
16:30:01 <sdake> we will all know the time
16:30:03 <sdake> i feel it coming
16:30:16 <sdake> diversity is part of it
16:30:22 <sdake> our community is very diverse
16:30:29 <sdake> which is why kolla rocks :)
16:30:51 <sdake> I just wanted to have this discussion at the beginning of the cycle so folks know this isn't a science project and we are not wasting time
16:31:10 <sdake> any questions?
16:31:25 <inc0__> sdake, we should get someone to run kolla on prod:)
16:31:35 <inc0__> later this release
16:31:38 <SamYaple> inc0__: got that covered
16:31:41 <sdake> inc0__ that would be helpful but not mandatory for openstack namespace
16:32:05 <sdake> #topic open discussion
16:32:41 <rhallisey> sdake, I'm going to propose a new blueprint that allow containers to support accepting config from a config file
16:32:45 <rhallisey> any thoughts?
16:32:55 <sdake> config file how?
16:33:15 <rhallisey> pass a config file to overwrite the existing config
16:33:21 <sdake> pass how
16:33:31 <rhallisey> using --env-file
16:33:48 <sdake> not familiar with that
16:33:54 <sdake> i could rtfm or you could tell me about it
16:34:02 <sdake> you mean our openstack.env file now?
16:34:45 <rhallisey> that would be one way to config on the fly
16:34:58 <SamYaple> https://review.openstack.org/#/c/182168/ rhallisey
16:34:58 <rhallisey> but I was also hoping to say overwrite nova.conf or something
16:35:13 <SamYaple> that takes environment variables and builds a config
16:35:13 <inc0__> sdake, I found something like that https://groups.google.com/forum/#!msg/docker-user/FyCWLC38Ueg/gh_1-NMc2NYJ
16:35:47 <sdake> rhallisey I think sam has a plan for that - is yours different in some way?
16:36:08 <SamYaple> rhallisey: i can work with you on that, im flexible, but i think our end goals are the same
16:36:44 <sdake> so I think its pretty clear we need to be able to support random config options to be viable
16:36:51 <rhallisey> SamYaple, ah ok ya that looks good
16:36:53 <sdake> however we get there wfm
16:37:02 <sdake> as long as it doesn't involve bindmounting the host os :)
16:37:16 <rhallisey> sdake, the reason I think this is important is because it will help us build up our stock of neutron and cinder containers
16:37:22 <rhallisey> since that config can be wild
16:37:31 <sdake> i hear ya
16:37:43 <sdake> just no -v /opt/kolla/etc:/etc ;)
16:37:47 <SamYaple> agreed rhallisey. my patch says ansible, but can easily be generated any number of ways
16:37:49 <sdake> that would make me cry inside
16:37:50 <inc0__> also that would help to decouple kolla containers from deployment methods
16:37:59 <SamYaple> sdake: is that a jab at yaodu
16:38:09 <rhallisey> ha
16:38:10 <sdake> do you do that in yaodu sam?
16:38:17 <SamYaple> .... maybe
16:38:20 <rhallisey> lol
16:38:31 <sdake> wasn't a jab at that, just the model
16:38:39 <sdake> I really want to avoid bindmounting
16:38:42 <SamYaple> :) i agree with you, thats why im here
16:38:43 <sdake> like REALLY want to avoid it
16:38:55 <sdake> and your dict env solves the problem nicely
16:39:38 <sdake> any other open discussion?
16:39:48 <rhallisey> docker-registry setup script
16:40:06 <rhallisey> I'm looking at that now if you think that's reasonable
16:40:20 <sdake> dockr registry takes 5 minutes to setup
16:40:34 <sdake> the only downside is it sets up on port 5000 by default (atleast in fedora)
16:40:36 <rhallisey> ya so it's an easy scirpt
16:40:51 <sdake> maybe taht should go in setup-docker
16:40:55 <sdake> and we should rename thatfile setup-env
16:41:25 <rhallisey> ya I'm not using 5000 :/
16:41:37 <sdake> ya clearly thats a bad idea ;-)
16:41:41 <mstachow> maybe docker-registry based on bridged network with mapped port?
16:41:56 <SamYaple> docker-registry is configurable port-wise
16:41:57 <inc0__> uhh...that would be counterintuitive
16:42:02 <SamYaple> i use it with 80 and 443
16:42:22 <SamYaple> it just an env variable i blieve
16:42:25 <rhallisey> it is
16:42:40 <rhallisey> it's pretty arbitrary
16:42:40 <sdake> people will either use setup-env or not
16:42:42 <sdake> i dont use it
16:42:52 <sdake> rather setup-docker
16:43:00 <rhallisey> ya makes sense
16:43:02 <sdake> its for new people to try our code out
16:43:11 <sdake> makes sense to me make a bug for it
16:43:15 <SamYaple> should we then have a "check" script to ensure the appropriate version and what not?
16:43:17 <sdake> since its not really blueprint material )
16:43:44 <sdake> samyaple good idea if anyone wants to tackle it
16:44:03 <sdake> so I totally blew the agenda
16:44:05 <SamYaple> probably could just back it in to setup-docker as an option (and run it after the full script as well)
16:44:16 <sdake> samyaple wfm - file bug :)
16:44:24 <SamYaple> k
16:44:35 <sdake> #topic continuous integration
16:44:52 <sdake> so, F Fantastic job jpeeler did on beating the gate into submission
16:45:08 <jpeeler> \o/
16:45:11 <sdake> we absolutely need an integration gate
16:45:13 <SamYaple> w00t
16:45:20 <sdake> this is required for openstack namespace in my opinion
16:45:26 <jpeeler> agreed
16:45:39 <sdake> we have more work to do
16:45:46 <sdake> we have image building working
16:45:49 <sdake> which was a serious chore
16:45:51 <sdake> what is next?
16:45:52 <jpeeler> just need a few setup scripts to be completed, think we're pretty close to being able to easily write a bunch of functional tests
16:46:15 <sdake> next in my mind is genenv
16:46:21 <sdake> next after that is kolla start
16:46:21 <jpeeler> although... i also thought the image building would be a lot simpler. so maybe i should strike easily out
16:46:37 <sdake> so genenv and kolla start with neutron
16:46:42 <sdake> how precisely are we going to  do that :)
16:46:52 <sdake> I think we need some type of bridging setup for neutron to run on one interface
16:47:37 <sdake> I want to gate on neutron not nova-network
16:48:06 <sdake> daneyon_ any chance you can figure that out?
16:48:18 <sdake> I tried and tried for like 5 days
16:48:29 <SamYaple> sdake: whats the struggle?
16:48:45 <sdake> we have a flat interface that should have no ip assigned that has internet access
16:48:54 <sdake> we have a public interface that is our management network
16:49:01 <sdake> I dont know if the builders have multiple ips
16:49:03 <sdake> but I suspect they do not
16:49:33 <SamYaple> can we use vlans?
16:49:36 <sdake> other projects set up a br-ex
16:49:45 <sdake> in the gate, I suspect not :)
16:49:52 <sdake> i mean use sure, but have it work correctly not sure
16:50:17 <SamYaple> is this multinode testing we are talking about?
16:50:24 <sdake> single node neutron
16:50:42 <jpeeler> it'd be good to have a working setup with only one network interface for usage outside of the gate too
16:50:50 <sdake> totally agree
16:51:14 <sdake> to me, this single interface mode of operation is our most critical need atm
16:51:21 <SamYaple> so is the network setup responsibility of the container, or external to the container?
16:51:31 <sdake> kolla setup scripts
16:51:35 <jpeeler> external
16:51:47 <sdake> like init-runonce
16:51:51 <sdake> or whatever its called now :)
16:51:53 <SamYaple> yea should be easy to generate a few interfaces, be it bridge or otherwise
16:52:11 <sdake> samyaple I tried and tried and couldn't get it to work correctly
16:52:22 <sdake> but I didn't follow yoda's advice :)
16:52:32 <sdake> so does someone want to do? :)
16:53:03 <SamYaple> when do you need it by? i fear taking on to much and not delivering becuase of a new baby
16:53:14 <sdake> at your own pace
16:53:18 <sdake> but at the head of the queue :)
16:53:32 <SamYaple> I can dig into it
16:53:36 <sdake> nice
16:53:44 <sdake> #action samyaple is going to save the universe :)
16:53:52 <SamYaple> agree
16:54:01 <sdake> :)
16:54:04 <sdake> good thing nobody has a shortage of egos here :)
16:54:15 <sdake> ok anything else on the integrated gate?
16:54:16 <SamYaple> how else would we get kolla in the openstack namespace
16:54:35 <jpeeler> sdake: how do images get updated in the docker registry?
16:54:36 <sdake> jpeeler are you planning to finish the rest of the gating work?
16:54:53 <SamYaple> jpeeler: you push new images to the registry
16:54:57 <jpeeler> nobody responded to my latest email about that topic
16:55:06 <jpeeler> http://lists.openstack.org/pipermail/openstack-dev/2015-May/064807.html
16:55:10 <jpeeler> maybe it was too crazy
16:55:13 <SamYaple> oh sorry i wasnt being sarcastic, i thought you meant local
16:55:14 <sdake> jpeeler no idea how to do that in an automated way that keeps the infra team happy
16:55:43 <sdake> if anyone has ideas how to push that doesn't take 5 hours i'm all ears
16:56:08 <sdake> jeblair suggested a periodic post job that woudl run every 10-20 commits
16:56:09 <SamYaple> i do, but it involves shrinking the containers
16:56:12 <sdake> to update the images
16:56:36 <sdake> samyaple 4 minutes on the clock go :)
16:57:09 <sdake> what is your proposal
16:57:24 <SamYaple> right now we build containers with n number of layers and that includes stuff that may or may not be removed, due to layers. in yaodu i squeezed off 75% of the size by exporting and rebuilding the container from a tarball
16:57:41 <SamYaple> the kolla containres are quite large
16:57:53 <SamYaple> smaller size==faster push?
16:57:59 <sdake> agree
16:58:09 <sdake> so exporing and rebuild only 1 container?
16:58:18 <SamYaple> it comes at the cost of removing container layer history (like a base image has no build history)
16:58:18 <rhallisey> docker save... docker load...?
16:58:30 <SamYaple> kinda, but it still uses the base image layer rhallisey
16:58:35 <SamYaple> and all the other tiers
16:59:01 <sdake> ok this slot is needed shortly lets overflow back into #kolla to finish the discussion on this proposal
16:59:04 <sdake> thanks for coming :)
16:59:13 <sdake> look forward to everyones contributions during liberty!
16:59:19 <sdake> lets rock it :)
16:59:22 <sdake> #endmeeting