20:01:16 <sdake_> #startmeeting kolla
20:01:17 <openstack> Meeting started Mon Oct 27 20:01:16 2014 UTC and is due to finish in 60 minutes.  The chair is sdake_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:21 <openstack> The meeting name has been set to 'kolla'
20:01:23 <sdake_> #topic rollcall
20:01:28 <daneyon> here
20:01:31 <sdake_> howdy folks!
20:01:43 <jrist> o/
20:01:46 <larsks> Howdy!
20:01:58 <radez> here
20:02:27 <jpeeler> hi
20:02:40 <sdake_> #topic agenda
20:02:52 <sdake_> #link https://wiki.openstack.org/wiki/Meetings/Kolla
20:02:59 <sdake_> there be the agenda, anyone have anything to add?
20:03:20 <sdake_> we should likley discuss meeting schedule for the next two weeks as a result of summit
20:04:05 <larsks> sdake_: nothing to add from me.
20:04:41 <sdake_> #topic Review goals of regarding Neutron in milestone #2
20:04:56 <sdake_> daneyon milestone #2 is scheduled for  friday
20:05:05 <sdake_> is that a possibility for your current work?
20:05:12 <sdake_> or is that not possible
20:05:27 <daneyon> i think it may need to move to milestone #3.
20:05:51 * larsks agrees.
20:05:52 <sdake_> how many weeks of dev do you tihnk it will require?
20:06:14 <daneyon> I am running down to my last few hours of getting multi-interfce working using docker-spotter. then I have to begin preparing for my Paris responsabilities.
20:06:26 <sdake_> ok
20:06:37 <sdake_> well since there is only 1 week, perhaps we should reschedule mliestone 2
20:06:47 <sdake_> when i made the schedule originally i didn't account for summit ;)
20:07:02 <larsks> sdake_: maybe we should push it to summit + 2 weeks?
20:07:02 <sdake_> and last week i think people were takinga breather :)
20:07:08 <daneyon> i would say 2 weeks after Paris, but it depends on the solution that we agree upon. i know the temp fix using spotter was not so well received.
20:07:09 <sdake_> ya that totally wfm
20:07:23 <sdake_> daneyon i personally dont care if its perfect
20:07:27 <daneyon> agree sumit + 2 weeks
20:07:32 <larsks> daneyon: code for "lars whined about it" :) Don't take my response as remotely authoritative!
20:07:32 <sdake_> i think having it work is important
20:07:34 <sdake_> and be reliable
20:07:47 <sdake_> is critical though
20:07:55 <sdake_> will the spotter mechanism be reliable and work?
20:07:58 <jrist> lol larsks
20:08:02 <daneyon> my biggest challenge is spotter.go
20:08:14 <larsks> daneyon: what is the challenge there?
20:08:42 <daneyon> Can anyone tell if spotter.go should be able to use a regex for the container name? If so, then it's a big win.
20:08:55 <sdake_> #info milestone #2 moved to November 21st
20:09:23 <sdake_> daneyon i am not hip enoug hto have the answer sorry :)
20:09:24 <daneyon> If not, then what about a container Hostname instead of a container name. the hostname (ie nova-network) is consistent.
20:10:01 <sdake_> so re milestone #2, i think the defining feature is pretty much neutron
20:10:16 <larsks> I think hostname is probably okay. If we wanted to be more careful, we should key off a specially named environment variable (SPOTTER_CONFIGURE_NETWORK=1 or something).
20:10:25 <larsks> But hostname should be fine for our use case, I think.
20:10:31 <daneyon> I am using spotter to run pipework kbr-ex 0/0 whenever it sees a contaienr start/stop/restart with a name nova-network (can also use neutron-openvswitch-agent) to create the veth for the 2nd interface.
20:11:06 <sdake_> #topic Milestone #2 blueprint assignment
20:11:10 <sdake_> nsaje howdy!
20:11:24 <daneyon> since the container names include a hash of some sort, spotter never implements the pipework command. I have successfully tested when I manually name the container nova-network.
20:11:34 <sdake_> #link https://blueprints.launchpad.net/kolla/milestone-2
20:12:04 <sdake_> anything in there for milestone #2 that should be pushed out past nov 21st?
20:12:07 <daneyon> larsks: agree on using the ENV
20:12:16 <larsks> daneyon: let's call that a decision, then :)
20:12:41 <larsks> sdake_: does "kube-centos-port" mean "convert everything to centos" or "maintain two separate sets of images"?
20:12:59 <sdake_> two sets
20:13:06 <sdake_> three in the future with other distros
20:13:07 <sdake_> etc
20:13:08 <larsks> Then I think we should push that out.
20:13:16 <sdake_> i am working on it this morning
20:13:20 <sdake_> i am almost done :)
20:13:28 <daneyon> larsks: cool. I just can't tell if the spotter.go code can use an ENV instead of a container name. Can you tell? https://github.com/discordianfish/docker-spotter/blob/master/spotter.go
20:13:34 <larsks> If we are still missing key services, now is not the time to be working on debugging version skew between centos/fedora.
20:13:42 <larsks> So I vote for pushing that out at least to ml3, if not further.
20:14:04 <sdake_> centos makes kolla more attractive to devs
20:14:13 <sdake_> since it means we have a multi distro os model
20:14:14 <daneyon> agree, I think all hands on deck to get core svcs working.
20:14:16 <sdake_> i get the version skew
20:14:25 <sdake_> how about this
20:14:29 <sdake_> fedora = supported
20:14:32 <sdake_> everything else = not supported
20:14:39 <larsks> I also think that supporting multiple versions is going to unnecessarily difficult until we have better config management in place.
20:14:40 <sdake_> your on your own, but its there to look at
20:14:58 <sdake_> we can add those notes to the release notes
20:15:07 <larsks> daneyon: Oh, I imagine we would need to patch spotter for that feature.  If it will work with hostnames, just do that for now.
20:15:33 <sdake_> radez jpeeler rhallisey thoughts on centos
20:15:45 <sdake_> i am super in favor of integrating that work sooner rather then later
20:15:54 <daneyon> larsks: OK. I will try hostnames.
20:16:02 <sdake_> with any caveats deemed apprioriate
20:16:03 <radez> I think it would give us a good basis to know what it may look like
20:16:16 <rhallisey> sdake_, sorry I was a tad late
20:16:17 <radez> maybe not supported but we can do some work on it to get an impression of what it will take to port
20:16:18 <sdake_> we can even put a big warning in the TLD saying "DONT USE THIS PLEASE USE FEDORA" as a filename
20:16:34 <jpeeler> sdake_: i tend to agree it's a bit soon, but if you do that it's probably fine ^
20:16:37 <radez> sdake_: I'd like to work on that centos port, but I'm tied up till after Paris to get staryted on it
20:16:50 <sdake_> radez i've almost got it finished this morning
20:16:55 <radez> heh
20:17:00 <larsks> sdake_: for all the images? and tested?
20:17:02 <sdake_> just loooking fo rfeedback if you think its helpful or not
20:17:05 <sdake_> not tested
20:17:20 <radez> that's just how it wlil be for me for another week or two... folks be stealin' my hackin'
20:17:23 <sdake_> for all images = lots of ln stuff
20:17:45 <larsks> sdake_: are we agreed that we should push this out for now? It sounds like it.
20:17:56 <sdake_> radez w epushed out to nov 21 milestone #2
20:18:17 <sdake_> i dont understand the concern if there are caveats
20:18:22 <radez> ack, I saw
20:18:40 <larsks> sdake_: the concern is that there are other things on which we should be spending our limited resources.
20:18:56 <sdake_> resources have been spent - patches nearly done
20:19:00 <larsks> sdake_: and that by introducing new platforms without appropriate config management in place we are rapidly going to end up with an unmaintainable pile of code.
20:19:19 <sdake_> caveat in new dirs - don't use - this is wip
20:19:27 <larsks> Anyway, enough discussion.  Shall we vote?
20:19:31 <sdake_> sure
20:19:39 <sdake_> core's only please
20:19:41 <sdake_> +1
20:19:58 <sdake_> wait
20:20:00 * larsks notes that "+1" means work on centos as part of ml2 "-1" means delay until ml3+
20:20:05 <sdake_> right :)
20:20:13 <sdake_> thanks thtas what the wait was for :)
20:20:22 <larsks> -1
20:20:23 * sdake_ too self centered i guess
20:20:27 <daneyon> -1
20:20:45 <radez> I'm a bit on the fence
20:20:49 <rhallisey> I'm going to have to -1, want to see more progress on the service front first
20:21:04 <radez> I think with paris I'll go -1 thought
20:21:10 <jpeeler> -1 for now
20:21:24 <sdake_> well then wfm i'll push that out
20:21:26 <daneyon> iwould like to see the fedora stuff kicking butt before supporting another distro.
20:21:28 <sdake_> ok so lets move on
20:21:42 <sdake_> we got a bunch of blueprints without owners
20:22:06 <sdake_> zaqar anyone want to take this?
20:22:10 <sdake_> should be relatively straight forward
20:22:18 <rhallisey> sdake_, sure I'll take it
20:22:21 <jpeeler> i'll take that one
20:22:23 <jpeeler> argh, too late
20:22:31 <sdake_> horizon?
20:22:32 <larsks> I will take  config-outside-container unless you really want it sdake, because that's one I care about.
20:22:37 <rhallisey> doesnt metter to me jpeeler
20:22:40 <sdake_> larsks works for me you take that one
20:22:41 <radez> I'll take os-config
20:22:53 <radez> os-cloud-config-in-base that is
20:22:55 <sdake_> ok go ahead and assign yourselves then and dlets have a refresh in 1 minute on the page
20:23:25 <radez> hm, I don't see how to assign myself?
20:23:27 <jpeeler> rhallisey: i kind of want it if you don't care - trying to keep work here overlapping with heat fairly strongly
20:23:41 <rhallisey> jpeeler, ya sure take it, I'll try horizon
20:23:44 <larsks> I vote for making horizon a higher priority than zaqar...
20:23:54 <radez> +1
20:23:55 <sdake_> larsks anyone can set priorties
20:23:59 <sdake_> feel free to change
20:24:03 <sdake_> these are jus tmy guesses :)
20:24:05 <larsks> Yes, but we should only decide as a group.
20:24:15 <rhallisey> nvm larsks has it
20:24:28 <sdake_> rhallisey he jus twants to change the prio you can still do the work
20:24:35 <rhallisey> ok
20:24:36 <sdake_> so its high rather then low iiuc
20:24:38 <larsks> sdake_: oh, he is planning on working on it too :)
20:24:53 <radez> sdake_: if I don't see a place to take a blueprint how to I put my name on it?
20:25:01 <daneyon> sdake: I can't seem to assign myself to the cluster vip bp.
20:25:04 <rhallisey> larsks, sure I'll join you
20:25:07 <sdake_> working on which
20:25:11 * sdake_ ughs
20:25:11 <larsks> rhallisey: yay!
20:25:23 <sdake_> daneyon i'll add you after the meeting ok?
20:25:37 <sdake_> radez click "assigned to" and clikc your name
20:25:41 <daneyon> sdake: thx
20:25:58 <radez> sdake_: I don't have a link to do that on the page
20:26:13 <sdake_> so we basically have 3 weeks of work time available of which 1 week is recovery from ODS
20:26:19 <sdake_> so more like 2 weeks
20:26:26 <sdake_> I feel like we can bring more content into m1
20:26:34 <sdake_> radez which one i'll set
20:26:40 <radez> os-cloud-config-in-base
20:27:33 <sdake_> launchpad just imploded
20:27:37 <sdake_> can someone else try to set it?
20:28:15 <larsks> assigned radez to os-cloud-config
20:28:31 <radez> thx larsks
20:28:49 <daneyon> larsks: I'll take this one: https://blueprints.launchpad.net/kolla/+spec/cluster-vip
20:29:06 <larsks> daneyon: okay, but that is currently set for milestone 3...
20:29:15 <sdake_> #topic Milestone #3 blueprint review
20:29:24 <larsks> daneyon: but you are now assigned!
20:29:30 <sdake_> #link https://blueprints.launchpad.net/kolla/milestone-3
20:29:40 <daneyon> larsks: OK, thx.
20:30:08 <larsks> sdake_: that url is a 404.
20:30:09 <jpeeler> milestone is mispelled https://blueprints.launchpad.net/kolla/mliestone-3
20:30:12 <rhallisey> sdake_, that link failed
20:30:35 <jpeeler> *misspelled
20:30:49 <sdake> wfm?
20:30:55 <larsks> sdake: mis spelled
20:30:55 <sdake> oh your right mispelled
20:30:56 <daneyon> milestone 3 #link https://blueprints.launchpad.net/kolla/mliestone-3
20:31:12 <sdake> trove and sahara
20:31:19 <sdake> foliks seem interested in full coverage
20:31:27 <sdake> so seems like those would be naturals to pull into milestone #2
20:32:06 <sdake> any takers?
20:32:15 <sdake> i'll take sahara
20:32:24 <larsks> milestone #2? Or #3?
20:32:29 <sdake> #2
20:32:34 <sdake> atm I have nothing assigned for milestone #2
20:32:53 <larsks> Okay.
20:33:00 <rhallisey> sdake, I can take trove and maybe larsks and I can combine for horizon
20:33:29 <sdake> cool your set
20:34:21 <sdake> #topic milestone #3 schedule
20:34:36 <sdake_> #topic milestone #3 schedule
20:35:19 <sdake> dec 12 makes the most sense to me
20:35:26 <sdake> then we can shut down for holidays for 3-4 weeks
20:35:39 <sdake> any objections to dec 12?
20:35:39 <daneyon> +1 on 12/12
20:35:44 <larsks> +1 for 12/12
20:35:52 <rhallisey> +1
20:35:52 <sdake> cool
20:36:09 <sdake> if you have more ideas for blueprints, feel free to file them away
20:36:14 <sdake> and we can jam them into milestone #3
20:36:19 <sdake> atm, milestone #3 is a little thin
20:36:24 <sdake> but maybe it will fill out later
20:36:39 <sdake_> #topic summit design session
20:36:56 <sdake> just a note for folks at summit, larsks will be leading a design summit session for Kolla
20:37:00 <sdake> larsks, have a link handy?
20:37:08 <larsks> Just a sec...
20:37:22 <larsks> http://kilodesignsummit.sched.org/event/14b3884522b5501a71404b481d5b45f1
20:37:33 <sdake> would be nice to get some text in there for attendees
20:37:42 <larsks> How do we do that?
20:37:47 <sdake> write it
20:37:57 <sdake> sec, let me get an etherpad rolling
20:38:25 <sdake> https://etherpad.openstack.org/p/kolla-design
20:38:57 <sdake> well for once I'm ata loss for words :)
20:39:10 <larsks> I will add some verbage after the meeting.
20:39:13 <sdake> lets spend 5 minutes editing that etherpad to come up with s omething
20:39:16 <larsks> Okay.
20:39:23 <sdake> I think its time spent together now is better use of time
20:41:11 <larsks> How about something like that?
20:42:00 <sdake> made a few edits to make it more snazzy
20:42:04 <larsks> Sure.
20:42:05 <sdake> anyone have anything to add?
20:42:40 <daneyon> looks good. can we add topics to the etherpad?
20:42:48 <sdake> sure
20:43:04 <daneyon> what about supporting a diff provisioning tool other than heat-kube?
20:43:27 <daneyon> since real deployments will most like use a config engine like puppet,ansible, etc..
20:43:30 <larsks> I would claim that we don't "support" heat-kube right now.  I keep telling people to look at the upstream docs unless they already have openstack and heat available.
20:43:56 <larsks> I also wonder how much we want to focus on "how to install kubernetes".  I sort of think we should focus on container design.
20:44:30 <daneyon> larsks: good point. maybe that's something we ask someone to work on outside of the core project?
20:44:31 <larsks> Brent extracted the config stuff from the heat templates and turned them into some standalone shell scripts.  I don't have a link handy right now...
20:44:36 <sdake> real deployments don't really want cm, because cm is a pita :)
20:44:59 <larsks> sdake: I think...most real deployments *do* want some sort of cm, actually.
20:45:00 <sdake> docker is the new config management
20:45:05 <larsks> But not necessarily what we would provide.
20:45:16 <sdake> ok any other topics?
20:45:21 <sdake> If not, I'll jsut delete that line
20:46:00 <sdake> ok, well I guess you can sort it out at summit
20:46:00 <daneyon> I think the project needs a tool to deploy kolla on bare metal systems. The aded layer of Heat is add'l complexity to an already complex thing.
20:46:15 <larsks> daneyon: That's what those shell scripts that I mentioned do...
20:46:26 <larsks> daneyon: I will try to track down a link,.
20:46:37 <sdake_> yup we should add to our docs
20:47:00 <daneyon> larsks: let me look into the scripts. they came across my path but i did not dive into them.
20:47:19 <daneyon> what about supporting AUFS instead of devicemapper?
20:47:21 <rhallisey> larsks, it's not in the bluejeans chat :( will have to ask Brent
20:47:30 <larsks> daneyon: AUFS isn't in-kernel, so I think no.
20:47:31 <daneyon> I have ran into issues with devicemapper
20:47:42 <larsks> daneyon: overlayfs just merged in the kernel, though, and signs point to that becoming the default.
20:47:42 <daneyon> larsks: OK
20:47:44 <sdake> so a topic can be storage?
20:47:52 <sdake> because we need persistent storage
20:47:55 <sdake> and we dont have it atm
20:47:57 <sdake> or much of it
20:48:11 <larsks> A topic for the summit discussion? Sure.
20:48:31 <daneyon> what about the gluster stuff in heat-kube?
20:48:41 <larsks> I think gluster is a good solution.
20:48:43 <larsks> There may be others.
20:48:46 <larsks> We can discuss them :)
20:48:50 <sdake> cool so that is good content for summit
20:48:51 <daneyon> OK
20:48:54 <sdake> any other topics?
20:49:04 <sdake> how about tripleo integration?
20:49:44 <larsks> sdake: Maybe worth looking into, but not something about which I can talk at all...
20:49:47 <sdake> I suspect that is why we g ot a session in the first place ;)
20:49:53 <daneyon> can u share a potential use case for tripleo integration?
20:49:56 <sdake> larsks that is where the tripleo developers give you their viewpoint
20:49:58 <sdake> not the otherway around
20:50:18 <sdake> the use case is having tripleo handle all the things rather then several installation tools
20:50:20 <larsks> And yet, it helps to have some familiarity with the tool, otherwise the discussion isn't really a discussion.
20:50:32 <sdake> well maybe they can discuss and you can listen
20:50:35 <sdake> and frame it that way :)
20:50:39 <larsks> And I don't have that, so I cannot discuss that in any meaningful way.
20:50:54 <sdake> does above sound ok?
20:51:13 <daneyon> i know little about tripleo
20:51:22 <sdake> here is what I'd do
20:51:41 <sdake> "I dont know much about tripleo but we want to integrate with it.  If there are tripleo devsi n the room, do youi have suggestions?"
20:51:50 <sdake> that should get the discussion kicked off
20:51:55 <sdake> and sit back and take notes :)
20:51:59 <daneyon> what about discussing potential kube/docker networking implementations and getting feedback?
20:52:06 <sdake> thats a good one
20:52:17 <sdake> looks like that is covered
20:52:21 <larsks> daneyon: Yes. I put external connectivity there already, but we can make that more general.
20:52:37 <sdake> ok it looks good
20:52:47 <sdake> I think we can just go with the abover
20:52:56 <sdake> I'll get the site updated if its not too late
20:53:21 <sdake> larsks/daneyon/radez can one of you cats tkae notes at the session and put in the etherpad
20:53:27 <larsks> sdake: Sure.
20:53:39 <daneyon> sdake: will do
20:53:45 <sdake> i'm sure it will just be a summary but t ry to take them live so I can get some context ;)
20:54:06 <sdake_> #topic open items
20:54:24 <sdake> any open discussion
20:54:26 <sdake> we have 5 minutes
20:55:07 <radez> sdake: yea I can help with that too, sry been a bit in and out here at the end
20:55:25 <sdake> thanks radez
20:55:29 <sdake> ok folks sounds like no open discussion
20:55:34 <sdake> thanks for coming :)
20:55:41 <daneyon> thanks!
20:55:41 <sdake_> #endmeeting