20:00:15 <sdake> #startmeeting kolla
20:00:15 <openstack> Meeting started Mon Jan 19 20:00:15 2015 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:19 <openstack> The meeting name has been set to 'kolla'
20:00:21 <sdake> #topic rollcall
20:00:27 <sdake> hey \o/ :)
20:00:27 <rhallisey> hi
20:00:31 <daneyon> hi
20:00:36 <sdake> hey folks
20:00:43 <sdake> anyone else around, jpeeler ?
20:00:45 <sdake> larsks?
20:00:54 <sdake> #topic agenda
20:01:01 <sdake> I didn't make an agenda today
20:01:05 * jpeeler is here
20:01:07 <sdake> I'm a bit lagged at work unforutnately
20:01:15 <daneyon> no worries
20:01:16 <sdake> I would like to speak about future direction of kolla a bit
20:01:17 <sdake> discuss it
20:01:26 <sdake> so we can determine what milestone #3 should be
20:01:31 <sdake> anyone else have anything to add?
20:01:45 <daneyon> nada
20:01:53 <sdake> #topic milestone #3 objectives
20:02:17 <sdake> I filed a review for tripleo specs:
20:02:53 <sdake> #link https://review.openstack.org/144199
20:03:16 <sdake> that basically says "lets use kubernetes and docker to build the tripleo cloud"
20:03:28 <sdake> got some pushback from Clint (tripleo PTL)
20:03:35 <sdake> I think his thinking is it s a bit too agressive
20:03:38 <sdake> he would like to see baby steps
20:03:53 <sdake> so the smallest baby step I cant think of is introducing containers to tripleo, rather then images
20:04:19 <sdake> I think that blueprint would pass the review +2/+A test
20:04:33 <sdake> folks interested in proceeding down that path?
20:04:48 <rhallisey> sure
20:05:26 <daneyon> so, would that mean using nova-docker instead of kolla?
20:05:36 <sdake> daneyon on that point I am unclear
20:05:38 <daneyon> or just not using kollaglue?
20:05:43 <daneyon> OK
20:05:49 <sdake> #link https://github.com/openstack/tripleo-image-elements/tree/master/elements
20:05:59 <sdake> this is how tripleo builds its images at this time
20:06:09 <sdake> it uses disk image builder to convert those elements above into different types of images
20:06:21 <daneyon> images seem to be a key benefit to the whole container selling point... or am I missing something?
20:06:34 <sdake> daneyon your not missing anything :)
20:06:49 <sdake> when DIB converts them, it converts them into "bootable" images
20:06:51 <sdake> not "docker" images
20:07:02 <sdake> so my propsal for this blueprint would be something along the lines of
20:07:11 <sdake> teach DIB how to create docker images from existing DIB elements
20:07:34 <sdake> teach tripleo how to launch DIB-built docker images instead of DIB-built disk images
20:07:35 <jpeeler> didn't someone say they were working on that?
20:07:56 <sdake> jpeeler mordred has indicated he is working on DIB to create docker images, but he was working on it 3 months ago and can't seem to get to it :)
20:08:02 <jpeeler> ah okay
20:08:05 <daneyon> i used the tripleo-image-elemnts stuff over a year ago when I was working on OpenShift heat templates. I remember it being a lot more painful than Docker images.
20:08:05 <sdake> he says its simple
20:08:07 <sdake> so maybe we can tackle it
20:08:25 <sdake> daneyon yay jpeeler wrote some ofthose ;)
20:08:42 <sdake> so yes, I think there is pain, but there is alot of gain
20:08:50 <sdake> the gain being, we can just integrate smoothly with a small baby step
20:08:56 <sdake> without disrupting what tripleo has already done
20:09:06 <sdake> unfortunately it disrupts what we have done
20:09:44 <sdake> so it would mean ceasing dev on the current docker images
20:09:53 <sdake> or atleast that not being our primary objective
20:10:06 <sdake> when we started, I had indicated we wanted to integrate with tripleo
20:10:09 <sdake> I think that is still the case
20:10:15 <sdake> as far as I can tell, this is the only way to do that
20:10:17 <sdake> thoughts?
20:11:13 <rhallisey> well in order for the project to grow that's what it might take
20:11:20 <rhallisey> in which case it would be worth it
20:12:06 <jpeeler> my understanding of devtest is that it originated from devstack. is there any code sharing between the two?
20:12:08 <sdake> daneyon jpeeler you have any thoughts?
20:12:22 <daneyon> I'm still thinking it through
20:12:23 <sdake> what is devtest
20:12:35 <daneyon> DIB says the following: OpenStack images are intended to be deployed and maintained using Nova + Heat.
20:13:03 <daneyon> That sounds different than what we would want to do from a Kolla standpoint.
20:13:18 <sdake> we would want to use heat  to orchestrate the cloud buildout
20:13:29 <sdake> we would want to use nova(possibly the docker driver) to deploy the images
20:13:29 <jpeeler> sdake: i thought devtest is the way most people install tripleO currently
20:13:41 <sdake> jpeeler news to me, mroe info int he brain :)
20:13:51 <daneyon> I would think we would want to deploy the Kolla "undercloud" using something like SaltStack, then use the magic of Docker images to deploy and maintain the Kolla undercloud
20:14:31 <sdake> not familiar with saltstack, mind providing a synopsis?
20:14:57 <daneyon> I just think removing all the benefits associated to Docker images sounds bad. Unless we can still provide an awesome devops experience by integrating with DIB.
20:15:16 <sdake> daneyon I absolutely believe that to be true
20:15:21 <sdake> (devops experience)
20:15:40 <sdake> the folks making the images will have a bit more pain
20:15:45 <sdake> since docker is dead simple to use
20:15:50 <sdake> and dib scripts kind of are painful :(
20:16:04 <sdake> but the deployment side will have the same devops experience - configure key/value pairs and launch your cloud
20:16:05 <daneyon> saltstack. puppet, ansible, etc.. is the standard devops tool for building/managing systems. I say SaltStack in particular since that's what GCE uses.
20:16:15 <sdake> got it
20:16:37 <sdake> i am not sure how the undercloud gets built today
20:16:43 <sdake> I think its puppet scripts or something similar
20:16:54 <sdake> its the overcloud where docker images shine for us
20:17:05 <sdake> because they allow inplace fast upgrades with nearly zero downtime
20:18:15 <sdake> daneyon I think the problem with the proposal you mentioned is it is essentially tripleo-redone-from-scratch
20:18:25 <sdake> which today, if we were doing tripleo, we would do :)
20:18:30 <sdake> but we have to integrate with what is there
20:18:39 <sdake> and change it to match what we want the future to look like
20:18:51 <daneyon> I guess it's hard for me to give a +1/-1 until I can think about it a bit more. I just want to make sure we don;t loose the benefits of Docker images just to get the project into tripleo
20:18:54 <sdake> in incrmental small steps - to preserve the community
20:19:18 <sdake> the alternative is to compete with tripleo afaik
20:19:33 <jpeeler> right, once you're part of a given community you have a bit more say
20:19:39 <sdake> tripleo has a bunch more devs then we have
20:19:41 <sdake> it would be good to merge
20:20:05 <daneyon> sdake: got it, but does that say something about tripleo? Is the initial direction of the project not so good since the Docker workflow is kinda a game changer?
20:20:39 <sdake> part of it is the docker workflow
20:20:43 <sdake> part of it is the kubernetes workflow
20:20:50 <sdake> I get why the kubernetes workflow is not suitable for tripleo
20:21:05 <sdake> it introduces a huge depndency into a one time operation of launching your cloud
20:21:06 <daneyon> Does tripleo need to go through big changes or is the right thing to retrofit kolla to fit tripleo by potentially loosing value?
20:21:43 <sdake> in retrospect I would not have involved kubernetes in kolla
20:21:50 <sdake> that was a big error in judgement on my part
20:22:15 <sdake> I had 20 people telling me to do it that way and no one saying no or experience to guide otherwise
20:22:21 <sdake> take it for what its worth :(
20:22:43 <daneyon> understandable
20:22:45 <sdake> as far as DIB being a pain to work with, I suspect we could - over time - change theworkflwo to NOT use dib
20:23:00 <sdake> but to use docker straight up
20:23:10 <sdake> *after* we get contianers integrated into tripleo
20:23:27 <sdake> tripleo is just more complication that isn't needed
20:23:30 <sdake> but thatwould be stpe #2
20:23:34 <sdake> rather dib is just more complication :)
20:23:43 <sdake> step #1 - teach dib about docker teach tripleo about docker
20:23:50 <sdake> step #2 - replace dib with native docker buildout
20:24:00 <sdake> step #3 - drink copious liquor
20:24:08 <rhallisey> lol
20:24:52 <sdake> what step #1 permits us to do is work on step #2 unimpeded within a larger community of developers
20:25:20 <daneyon> i think the operators wanting containers will want the same Docker workflow. They will care more about the Docker experience than needing to use tripleo to gain Dockerized OS services.
20:25:36 <daneyon> I would like to think this through some more.
20:25:45 <sdake> cool well lets chat next week about it
20:25:53 <sdake> I guess I'll kick off the blueprint review this week and see what happens
20:25:58 <rhallisey> ya agreed
20:26:07 <sdake> #topic open discussion
20:26:16 <sdake> anyone hae any discussion they would like to have?
20:26:28 <rhallisey> nope
20:26:37 <daneyon> no
20:26:43 <sdake> ok then, I'll end meeting
20:26:45 <sdake> thanks all for coming :)
20:26:47 <sdake> #endmeeting