19:59:43 <sdake> #startmeeting kolla
19:59:44 <openstack> Meeting started Mon Jan  5 19:59:43 2015 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:59:47 <sdake> greetings!
19:59:48 <openstack> The meeting name has been set to 'kolla'
19:59:52 <sdake> #topic rollcall
19:59:57 <rhallisey> hi
19:59:59 <sdake> who made it through the new year :)
20:00:11 <rhallisey> Happy New Year!
20:00:28 <sdake> daneyon you happen to be around?
20:00:29 <sdake> larsks?
20:00:32 <daneyon> here
20:00:34 <sdake> jpeeler?
20:00:38 <larsks> Howdy!
20:00:46 <larsks> Happy new year!
20:00:54 <sdake> hey larsks, I promise I wont bother you much except for these meetings for your expertise ideas :)
20:00:55 <daneyon> yay 2015!
20:01:01 <sdake> ya, survived another year
20:01:02 <sdake> whew
20:01:12 <sdake> meteor scheduled to hit next year I'm sure given my luck :)
20:01:20 <daneyon> hah
20:01:22 <daneyon> a
20:01:37 <sdake> #topic agenda
20:01:45 <sdake> #link https://wiki.openstack.org/wiki/Meetings/Kolla
20:01:57 <sdake> Anyone have anything to add to the agenda?
20:02:28 <daneyon> nope
20:02:32 <sdake> #topic Milestone #2 agenda
20:02:42 <sdake> #topic Milestone #2 discussion
20:02:44 <sdake> #undo
20:02:45 <sdake> #undo
20:02:45 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3bfe190>
20:02:46 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3bfe850>
20:02:50 <sdake> #topic Milestone #2 discussion
20:02:54 <sdake> there we go
20:03:01 <sdake> ok I ended up not pushing the tag last year
20:03:15 <sdake> the motivating factor was that heat-kubernetes was busted along with all our scripts
20:03:31 <sdake> mainly because fedora upgraded kubernetes and changed how all the configuration worked
20:03:42 <daneyon> yay
20:03:43 <sdake> I think the fallout from that is almost settled minus review:
20:04:05 <rhallisey> ya I'll fix that soon
20:04:12 <sdake> #link https://review.openstack.org/143548
20:04:21 <sdake> rhallisey if you can fix today, I'll release the tag tomorrow
20:04:26 <sdake> I'd like to get cracking on Milestone #3
20:04:32 <rhallisey> ok cool
20:04:44 <sdake> anyone have any remianing items that need to be fixed for milestone #2?
20:04:56 <sdake> I tested with rhallisey's script, and it all seems to work (after I updated the images)
20:05:31 <rhallisey> sdake, should I add a feature that detects the version?
20:05:41 <sdake> rhallisey just expect the latest
20:05:48 <rhallisey> ok
20:05:51 <sdake> and if someone complains, we can point them at our prebuilt fedora atomic image
20:06:05 <sdake> #topic Creating a deployment library for use by TripleO
20:06:17 <jpeeler> little late, sorry
20:06:23 <sdake> #link https://review.openstack.org/#/c/144199/
20:06:25 <sdake> no sweat jeff
20:06:34 <sdake> so if folks would take a few minutes to read that over
20:06:50 <sdake> the basic idea is to create a deployment and upgrade/downgrade library for use by TripleO for containers
20:07:02 <sdake> and then tripleo would inherit containers by using the library
20:07:20 <sdake> but i'll give until 10 after for folks to read through the proposal
20:10:13 <sdake> ok, times up - hopefully you had a chance to read, initial thoughts?
20:11:21 <sdake> I asked Clint to read through the proposal
20:11:27 <daneyon> makes sense
20:11:27 <sdake> he suggested we split it up into steps
20:11:50 <sdake> as things stand now, I think we are a bit stuck in the mud with no further progress to be made without progressing down a path similar to this
20:11:57 <sdake> I thought Magnum would be there in time for this, but it wont be
20:12:39 <sdake> so I think splitting the proposal would be #1: Make deployment work with containers instead of servers (sans Kubernetes)
20:12:47 <sdake> #2 would be a kubernetes/atomic connection
20:13:19 <sdake> I know larsks is swsamped for time, but do other folks have time to work on this assuming proposal #1 is introduced?
20:13:27 <sdake> It may mean reworking how our container configuration is done a bit
20:13:34 <sdake> to be more compatible with existing tripleo worldview
20:14:29 <daneyon> I need to dig into tripleo to better understand
20:14:39 <sdake> ya, I really have questions about *where* this goes
20:14:44 <sdake> Tuskar has been mentioned
20:15:07 <sdake> If we can abstract Tuskar's deployment api, we can introduce whatever changes we like
20:15:21 <sdake> and then kolla can join the tripleo program permanently
20:15:30 <rhallisey> sdake, think I should be ok to contribute will know more soon
20:15:37 <sdake> thanks rhallisey
20:15:45 <rhallisey> I anticipate it being no problem
20:15:49 * jpeeler doesn't really know
20:15:51 <sdake> any further questions?
20:16:07 <sdake> neither do I jpeeler, neither do I :)
20:16:07 <jpeeler> however, wouldn't the changes be non-service specific anyway?
20:16:21 <sdake> well, tripleo uses something called os-rfresh-config
20:16:32 <sdake> when someone chnages a config value, tripleo runs ORC across all machines
20:16:49 <sdake> in our model, when someone changes a config value, the container is killed and restarted
20:17:06 <sdake> the container input values must match those that ORC is expecting I suspect
20:17:44 * rhallisey needs to learn some tripleo
20:17:55 <sdake> yup, thiys means for all of us learning how tripleo works
20:17:59 <sdake> which shoudl be fun :)
20:18:03 <rhallisey> :)
20:18:19 <sdake> the next topic agenda is adding flannel support to heat-kubernetes
20:18:28 <sdake> but I see larsks, the overachiever he is, has already done that all by himself :)
20:18:35 <sdake> so I'll move on to open discussion
20:18:40 <sdake> #topic Open discussion
20:19:14 <sdake> rhallisey as soon as you have a review up for that change, ping a couple guys in the core to getit merged and let me know so I can tag it
20:19:22 <jpeeler> may i ask why flannel was chosen over weave?
20:19:25 <sdake> its a good thing I didn't push teh tag last year
20:19:28 <rhallisey> sdake, sounds good
20:19:39 <sdake> jpeeler flannel is default in coreos and atomic, weave is not available in either distribution
20:19:40 <larsks> jpeeler: it seems to be what upstream (kubernetes) is looking at.
20:19:50 <larsks> And yeah, it's included by default.
20:19:56 <daneyon> flannel was discussed as a replacement option around Turkey Day
20:20:08 <larsks> Also, I like the fact that it includes vxlan support.
20:20:15 <daneyon> The k8s team suggests flannel
20:20:37 <jpeeler> atomic uses flannel?
20:20:39 <sdake> there is a third option called pipeworks
20:20:45 <sdake> yes atomic uses flannel
20:20:49 <larsks> jpeeler: well, no.
20:20:55 <larsks> jpeeler: but flannel can use vxlan.
20:21:12 <larsks> The advantage there is that flannel is outside of the communication path, so you can restart it without affecting connectivity.
20:21:29 * larsks answers the wrong question.
20:21:30 <sdake> ya control plane ftw
20:21:32 * larsks hides.
20:21:38 <daneyon> flannel supports multiple backends, one of them being vxlan the other being simply UDP encap
20:21:57 <sdake> atomic *only* ships flannel atm
20:22:00 <larsks> Yeah.  I always feel icky when someone writes their own brand new transport...
20:22:02 <sdake> that could obviously changein the future
20:22:25 <sdake> I doubt coreos would ship anything but flannel
20:22:29 <sdake> since they wrote it oriignally
20:22:31 <sdake> NIH and all that
20:22:47 <sdake> which is good, we have a standard, and dont have to jerk around with two implementations in the templates :)
20:24:36 <sdake> anyone else have any open discussion?
20:24:46 <sdake> I'll give a couple minutes then conclude the meeting
20:25:18 <sdake> if folks could take time to watch that review posted above, I'd appreciate any feedback or comments you have
20:25:30 <sdake> obviously everyone's time is important, to getting people to actually read the spec changes is difficult :)
20:25:38 <sdake> to getting/so getting
20:25:52 <daneyon> i'll keep an eye out
20:25:57 <sdake> thanks folks
20:26:01 <sdake> i'll conclude the meting now
20:26:03 <sdake> #endmeeting