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

Reply via email to