Open Stack

On 09/23/2014 07:15 PM, John Griffith wrote:
>
>
> On Tue, Sep 23, 2014 at 7:06 PM, Steven Dake <sdake at redhat.com 
> <mailto:sdake at 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 [sdake at redhat.com <mailto:sdake at 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 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
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140923/a39f3571/attachment.html>