Open Stack

First, Kevin, please try to figure out a way to reply in-line when you're
replying to multiple levels of threads. Even if you have to copy and
quote it manually.. it took me reading your message and the previous
message 3 times to understand the context.

Second, I don't think anybody minds having a control plane for each
level of control. The point isn't to replace the undercloud, but to
replace nova rebuild as the way you push out new software while
retaining the benefits of the image approach.

Excerpts from Fox, Kevin M's message of 2014-09-25 09:07:10 -0700:
> Then you still need all the kubernetes api/daemons for the master and slaves. If you ignore the complexity this adds, then it seems simpler then just using openstack for it. but really, it still is an under/overcloud kind of setup, your just using kubernetes for the undercloud, and openstack for the overcloud?
> 
> Thanks,
> Kevin
> ________________________________
> From: Steven Dake [sdake at redhat.com]
> Sent: Wednesday, September 24, 2014 8:02 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and Manage OpenStack using Kubernetes and Docker
> 
> On 09/24/2014 03:31 PM, Alan Kavanagh wrote:
> Steven
> I have to ask what is the motivation and benefits we get from integrating Kubernetes into Openstack? Would be really useful if you can elaborate and outline some use cases and benefits Openstack and Kubernetes can gain.
> 
> /Alan
> 
> Alan,
> 
> I am either unaware or ignorant of another Docker scheduler that is currently available that has a big (100+ folks) development community.  Kubernetes meets these requirements and is my main motivation for using it to schedule Docker containers.  There are other ways to skin this cat - The TripleO folks wanted at one point to deploy nova with the nova docker VM manager to do such a thing.  This model seemed a little clunky to me since it isn't purpose built around containers.
> 
> As far as use cases go, the main use case is to run a specific Docker container on a specific Kubernetes "minion" bare metal host.  These docker containers are then composed of the various config tools and services for each detailed service in OpenStack.  For example, mysql would be a container, and tools to configure the mysql service would exist in the container.  Kubernetes would pass config options for the mysql database prior to scheduling and once scheduled, Kubernetes would be responsible for connecting the various containers together.
> 
> Regards
> -steve
> 
> 
> 
> From: Steven Dake [mailto:sdake at redhat.com]
> Sent: September-24-14 7:41 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and Manage OpenStack using Kubernetes and Docker
> 
> On 09/24/2014 10:12 AM, Joshua Harlow wrote:
> Sounds like an interesting project/goal and will be interesting to see where this goes.
> 
> A few questions/comments:
> 
> How much golang will people be exposed to with this addition?
> 
> Joshua,
> 
> I expect very little.  We intend to use Kubernetes as an upstream project, rather then something we contribute to directly.
> 
> 
> Seeing that this could be the first 'go' using project it will be interesting to see where this goes (since afaik none of the infra support exists, and people aren't likely to familiar with go vs python in the openstack community overall).
> 
> What's your thoughts on how this will affect the existing openstack container effort?
> 
> I don't think it will have any impact on the existing Magnum project.  At some point if Magnum implements scheduling of docker containers, we may add support for Magnum in addition to Kubernetes, but it is impossible to tell at this point.  I don't want to derail either project by trying to force them together unnaturally so early.
> 
> 
> I see that kubernetes isn't exactly a small project either (~90k LOC, for those who use these types of metrics), so I wonder how that will affect people getting involved here, aka, who has the resources/operators/other... available to actually setup/deploy/run kubernetes, when operators are likely still just struggling to run openstack itself (at least operators are getting used to the openstack warts, a new set of kubernetes warts could not be so helpful).
> 
> Yup it is fairly large in size.  Time will tell if this approach will work.
> 
> This is an experiment as Robert and others on the thread have pointed out :).
> 
> Regards
> -steve
> 
> 
> On Sep 23, 2014, at 3:40 PM, Steven Dake <sdake at redhat.com<mailto:sdake at redhat.com>> wrote:
> 
> 
> Hi folks,
> 
> I'm pleased to announce the development of a new project Kolla which is Greek for glue :). Kolla has a goal of providing an implementation that deploys OpenStack using Kubernetes and Docker. This project will begin as a StackForge project separate from the TripleO/Deployment program code base. Our long term goal is to merge into the TripleO/Deployment program rather then create a new program.
> 
> 
> 
> Docker is a container technology for delivering hermetically sealed applications and has about 620 technical contributors [1]. We intend to produce docker images for a variety of platforms beginning with Fedora 20. We are completely open to any distro support, so if folks want to add new Linux distribution to Kolla please feel free to submit patches :)
> 
> 
> 
> Kubernetes at the most basic level is a Docker scheduler produced by and used within Google [2]. Kubernetes has in excess of 100 technical contributors. Kubernetes is more then just a scheduler, it provides additional functionality such as load balancing and scaling and has a significant roadmap.
> 
> 
> The #tripleo channel on Freenode will be used for Kolla developer and user communication. Even though we plan to become part of the Deployment program long term, as we experiment we believe it is best to hold a separate weekly one hour IRC meeting on Mondays at 2000 UTC in #openstack-meeting [3].
> 
> 
> This project has been discussed with the current TripleO PTL (Robert Collins) and he seemed very supportive and agreed with the organization of the project outlined above. James Slagle, a TripleO core developer, has kindly offered to liase between Kolla and the broader TripleO community.
> 
> 
> 
> I personally feel it is necessary to start from a nearly empty repository when kicking off a new project. As a result, there is limited code in the repository [4] at this time. I suspect folks will start cranking out a kick-ass implementation once the Kolla/Stackforge integration support is reviewed by the infra team [5].
> 
> 
> 
> The initial core team is composed of Steven Dake, Ryan Hallisey, James Lebocki, Jeff Peeler, James Slagle, Lars Kellogg-Sedman, and David Vossel. The core team will be reviewed every 6 weeks to add fresh developers.
> 
> 
> Please join the core team in designing and inventing this rockin' new technology!
> 
> 
> Regards
> -steve
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> 
> [1] https://github.com/docker/docker [2] https://github.com/GoogleCloudPlatform/kubernetes
> 
> [3] https://wiki.openstack.org/wiki/Meetings/Kolla [4] https://github.com/jlabocki/superhappyfunshow [5] https://review.openstack.org/#/c/122972/
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OpenStack-dev mailing list
> 
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>