Excerpts from Steven Dake's message of 2014-09-23 15:40:29 -0700:
> *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.

You had me at Docker.. 

"Kubernetes establishes robust declarative primitives for maintaining
the desired state requested by the user. We see these primitives as
the main value added by Kubernetes. Self-healing mechanisms, such as
auto-restarting, re-scheduling, and replicating containers require active
controllers, not just imperative orchestration."

But the bit above has me a bit nervous...

I'm not exactly ignorant of what declarative orchestration is, and of
late I've found it to be more trouble than I had previously imagined it
would be. All of the features above are desirable in any application,
whether docker managed or not, and have been discussed for Heat
specifically. I'm not entirely sure I want these things in my OpenStack
deployment, but it will be interesting to see if there are operators who
want them bad enough to deal with the inherent complexities of trying to
write such a thing for an application as demanding as OpenStack.

Anyway, I would definitely be interested in seeing if we can plug it
into the interfaces we already have for image building, config file and
system state management. Thanks for sharing, and see you in the
deployment trenches. :)

OpenStack-dev mailing list

Reply via email to