On 09/23/2014 07:15 PM, John Griffith wrote:
On Tue, Sep 23, 2014 at 7:06 PM, Steven Dake <sd...@redhat.com
<mailto:sd...@redhat.com>> wrote:
On 09/23/2014 05:38 PM, Fox, Kevin M wrote:
I'm interested in how this relates/conflicts with the TripleO
goal of using OpenStack to deploy OpenStack.
It looks like (maybe just superficially) that Kubernetes is
simply a combination of (nova + docker driver) = container
schedualer and (heat) = orchestration. They both schedule
containers, will need advanced scheduling like "ensure these two
containers are on different servers (nova ServerGroups),
autoscale resources, hook up things together, have a json
document that describes the desired state, etc... If that's the
case, it seems odd to use an OpenStack competing product to
deploy a competitor of Kubernetes. Two software stacks to learn
how to debug rather then just one.
Kevin,
Thanks for the feedback.
There are two orthogonal points you address re competitiveness.
One is the deployment program (which Kolla intends to be a part
of). The deployment program includes an implementation
(tripleo). TripleO is focused around using OpenStack to deploy
OpenStack. Kolla is focused around using Kubernetes to deploy
OpenStack. But they both fit into the same program, and at some
point they may even be remerged into both using OpenStack to
deploy OpenStack. Time will tell.
IMO Kubernetes is not competitive with OpenStack. The way in
which the Kolla project uses them is in fact complimentary. In a
perfect world OpenStack's container service (Magnum) + Heat could
be used instead of Kubernetes. The problem with that approach is
the container service for OpenStack is not functional and not
integrated into the release.
It is indeed true that another software stack must be learned. We
hope to abstract most/all of the differences so the actual
maintenance difference (ie what must be learned) presents a small
learning footprint.
Maybe I'm just totally misunderstanding what Kubernetes is trying
to accomplish though. I'm not trying to stur up trouble here. I
just really want to understand how these two technologies fit
together.
I don't see you stirring up trouble :) Essentially this project
proposes an alternative method for deploying OpenStack (ie not
using OpenStack, but using Kubernetes).
I did run the idea by Robert Collins (current TripleO PTL) first
before we got cracking on the code base. He indicated the
approach was worth experimenting with.
So I think it's a cool idea and worth looking at as you have said.
But I'm very confused by your statements, it seems to me that there's
a misunderstanding, either in what Triple'O is, or something else
entirely.
Given that Triple'O stands for Openstack On Openstack I'm not sure how
you separate the OpenStack piece from the project? Don't get me
wrong, I'm certainly not saying one way is better than the other etc.
just that the statements here are a bit confusing tome.
John,
There is a deployment program - tripleo is just one implementation. We
went through this with Heat and various projects that want to extend
heat (eg Murano) and one big mistake I think Murano folks made was not
figuring out where there code would go prior to writing it. I'm only
making a statement as to where I think it should belong.
Also, it seems REALLY strange that Triple'O hasn't even graduated and
my limited understanding is that it still has a ways to go and we're
proposing alternate implementations of it. Very odd IMO.
Our goal is deploying OpenStack using containers. TripleO could have
this same goal, but at the present it does not (I could be mistaken
here, please feel free to correct if I am incorrect). It rather prefers
to deploy on bare metal. We are just focusing on this particular point,
(openstack in containers on bare metal). I spoke with Robert for quite
awhile about integration time and we were both in agreement early or
late integration is not a concern for us - getting something working for
containers seemed more compelling.
That being said, I'd love to see some details on what you have in mind
here. I don't necessarily see why it needs to be an "OpenStack
Project" per-say as opposed to a really cool Open Source Project for
deploying OpenStack containers (or whatever it is exactly that you
have in mind).
It doesn't have to necessarily go into the deployment program. My main
motivation at this point for using stackforge and attaching it to
OpenStack is I desperately want to use the OpenStack workflow since our
workflow rocks!
Regards
-steve
Regards
-steve
Thanks,
Kevin
------------------------------------------------------------------------
*From:* Steven Dake [sd...@redhat.com <mailto:sd...@redhat.com>]
*Sent:* Tuesday, September 23, 2014 3:40 PM
*To:* OpenStack Development Mailing List
*Subject:* [openstack-dev] [all][tripleo] New Project -> Kolla:
Deploy and Manage OpenStack using Kubernetes and Docker
*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
<https://github.com/docker/docker> [2]
https://github.com/GoogleCloudPlatform/kubernetes
<https://github.com/GoogleCloudPlatform/kubernetes>
[3] https://wiki.openstack.org/wiki/Meetings/Kolla
<https://wiki.openstack.org/wiki/Meetings/Kolla> [4]
https://github.com/jlabocki/superhappyfunshow
<https://github.com/jlabocki/superhappyfunshow> [5]
https://review.openstack.org/#/c/122972/
<https://review.openstack.org/#/c/122972/>
*
*
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
