Open Stack

Bogdan,

I recognize English isn’t your first language, so forgive me if I have mis-parsed your message.  I think the question you are asking is “Can we have cooperation to standardize on how best to do OpenStack on Kubernetes”.  We tried an analog of that with Mirantis around Mesos, and that resulted in many derived works, one of which was fuel-ccp.  Fuel has made it abundantly clear they intend to compete with Kolla, which is fine.  I recognize we are one community and need to put OpenStack first here, and project teams second, but I also fail to see how training the Fuel team with the choices Kolla has made in implementation puts OpenStack first.

Standard organizational best practice with competitive teams in any organization is either to stamp out the competition or let them compete independently to grow the pie for everyone. The activity you propose would not put OpenStack first because of this organizational best practice.

Our code base is completely open.  Our irc channels are completely open.  Our mailing list participation is completely open.  Our architecture discussions are completely open.  Our project is OPEN.  If you really want to participate in Kolla the door remains open.  I find it hard to see a way for that to happen given the history and Mirantis’s stated intent, but anything is possible if the right people change their minds.

Regards
-steve

On 9/23/16, 8:37 AM, "Bogdan Dobrelya" <bdobrelia at mirantis.com> wrote:

    Yeah, would be very nice to have/reuse a place for highest level and
    projects independent specs to outline key architecture decisions like
    (WARN [tl;dr]: biased examples from a non existent prototype go below):
    
    * Shared nothing for stateful DB/MQ components (this means no shared
    storage for state keeping, but replicas instead)
    * And maybe place stateful and SDN/NFV/HW bound components *out* of COE
    scope (they are well known to like only
    stateless/serverless/schemaless/overlay only unicorns. A joke!..)
    * CM tools-agnostic containers build pipelines
    * Building images from sources but ship only artifacts w/o build deps
    * No entry points magic in build pipeline for containers images to be
    spawned by COE platforms as apps.
    * Rework components to support 12 factor apps requirements, e.g.
    redirect to stdout/stderr only, do not use implicit communication
    channels etc.
    * Runtime only data driven approach (no j2 templates for build pipeline
    please!)
    and more things...
    
    On 22.09.2016 16:49, Flavio Percoco wrote:
    > On 22/09/16 10:09 -0400, Davanum Srinivas wrote:
    >> Flavio
    >>
    >> Please see below:
    >>
    >> On Thu, Sep 22, 2016 at 7:04 AM, Flavio Percoco <flavio at redhat.com>
    >> wrote:
    >>> Greetings,
    >>>
    >>> I've recently started looking into the container technologies around
    >>> OpenStack.
    >>> More specifically, I've been looking into the tools that allow for
    >>> deploying
    >>> OpenStack on containers, which is what I'm the most interested in
    >>> right now
    >>> as
    >>> part of the TripleO efforts.
    >>>
    >>> I'm familiar with the Kolla project and the tools managed by this
    >>> team. In
    >>> fact,
    >>> TripleO currently uses kolla images for the containerized nova-compute
    >>> deployment.
    >>>
    >>> I am, however, looking beyond a docker based deployment. I'd like to
    >>> explore
    >>> in
    >>> more depth a Kubernetes based deployment of OpenStack. I'm familiar with
    >>> both
    >>> kolla-kubernetes and fuel-ccp, their structure and direction*. Both
    >>> projects
    >>> have now advanced a bit in their implementations and made some
    >>> decisions.
    >>>
    >>> As someone that started looking into this topic just recently, I'd
    >>> love to
    >>> see
    >>> our communities collaborate more wherever possible. For example, it'd be
    >>> great
    >>> to see us working on a reference architecture for deploying OpenStack on
    >>> kubernetes, letting the implementation details aside for a bit. I'd
    >>> assume
    >>> some
    >>> folks have done this already and I bet we can all learn more from it
    >>> if we
    >>> work
    >>> on this together.
    >>>
    >>> So, let me go ahead and ask some further questions here, I might be
    >>> missing
    >>> some
    >>> history and/or context:
    >>>
    >>> - Is there any public documentation that acts as a reference
    >>> architecture
    >>> for
    >>>  deploying OpenStack on kubernetes?
    >>> - Is this something the architecture working group could help with?
    >>> Or would
    >>> it
    >>>  be better to hijack one of kolla meetings?
    >>>
    >>> The restult I'd love to see from this collaboration is a reference
    >>> architecture
    >>> explaining how OpenStack should be run on Kubernetes.
    >>
    >> At this moment, fuel-ccp-* is an experiment, it's not under
    >> governance, there is no expectation of any releases, there are no
    >> specs or docs that i know of. So kolla/kolla-kubernetes is probably
    >> the best accumulator of kubernetes knowledge specifically about
    >> running openstack.
    >>
    >> Note that tcpcloud folks may also have something, but haven't seen any
    >> public information or reference architecture from them. Definitely
    >> don't know of any plans from that team as well to open up and share.
    > 
    > Yeah, I know all of the above, which is why I said I don't really care
    > about the
    > implementation detail of things. I think the knowledge the folks in
    > fuel-ccp
    > have and the knowledge folks in the kolla team have could produce a base
    > knowledge for folks looking into deploying OpenStack on kubernetes.
    > 
    > It'd be great to see this happening and I'm sure teams would benefit
    > from it
    > too.
    > 
    > Flavio
    > 
    >>> Thanks in advance. I look forward to see us collaborate more on this
    >>> area,
    >>> Flavio
    >>>
    >>> * thanks to all fuel and kolla contributors that helped me understand
    >>> better
    >>> the
    >>>  work in each of these projects and the direction they are headed
    >>> .
    >>> -- 
    >>> @flaper87
    >>> Flavio Percoco
    >>>
    >>> __________________________________________________________________________
    >>>
    >>> OpenStack Development Mailing List (not for usage questions)
    >>> Unsubscribe:
    >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >>>
    >>
    >> Thanks,
    >> Dims
    >>
    >> -- 
    >> Davanum Srinivas :: https://twitter.com/dims
    >>
    >> __________________________________________________________________________
    >>
    >> OpenStack Development Mailing List (not for usage questions)
    >> Unsubscribe:
    >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    > 
    > 
    > 
    > __________________________________________________________________________
    > OpenStack Development Mailing List (not for usage questions)
    > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    > 
    
    
    -- 
    Best regards,
    Bogdan Dobrelya,
    Irc #bogdando
    
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev