Open Stack

On 22/09/16 20:55 +0000, Steven Dake (stdake) wrote:
>Flavio,
>
>Apologies for delay in response – my backlog is large.
>
>Forgive me if I parsed your message incorrectly.

It's probably me failing to communicate my intent or just the intent not being
good enough or worth it at all.

> It came across to me as “How do I blaze a trail for OpenStack on Kubernetes?”.  That was asked of me personally 3 years ago which led to the formation of the Kolla project inside Red Hat.  Our initial effort at that activity failed.  Instead we decided kubernetes wasn’t ready for trailblazing in this space and used a far more mature project (Ansible) to solve the “OpenStack in Containers” problems and build from there.
>
>We have since expanded our scope to re-solve the “How do I blaze a trail for Openstack on Kubernetes?” question since Kubernetes is now ready for this sort of trailblazing.  Fuel and several other folks decided to create derived works of the Kolla community’s innovations in this area.  I would contend that Fuel didn’t need to behave in such a way because the Kolla community is open, friendly, mature, diversely affiliated, has a reasonable philosophy and good set of principles as well as a strong leadership pipeline.
>
>Rather than go blaze a trail when one already exists or create a derived work, why not increase your footprint in Kolla instead?  Red Hat has invested in Kolla for some time now, and their footprint hasn’t magically disappeared over night.   We will give you what you want within reasonable boundaries (the boundaries all open-source projects set of their contributors).  We also accept more work than the typical OpenStack project might, so it’s not like you will have to bring donuts into the office for every patch you merge into Kolla.
>
>As to your more direct question of reference architecture, that is a totally loaded term that I’ll leave untouched.
>
>To answer your question of “Does Kolla have a set of best practices” the answer is yes in kolla-ansible and kolla itself and strongly forming set of best practices in kolla-kubernetes.

As I mentioned in my email, I don't really care about the implementation right
now. I'm not trying to change the current teams, goals, or anything. I would go
as far as saying that the acknowledgement of the existing teams in my original
email was merely a way to identify a set of teams that might be interested in
writing this reference architecture.

Is it a loaded term? Maybe, is this point relevant for my original question? I'd
say no. It doesn't matter what we call this, not to me, not right now.

Don't get me wrong, I understand where you're coming from and I appreciate your
input. Unfortunately, I think you addressed my email from the wrong angle as I'm
a step (or many steps) early from doing any kind of implementation and I tried
to be clear about this in my original email.

I can contribute to kolla-kubernetes all you want but that won't give me what I
asked for in my original email and I'm pretty sure there are opinions about the
"recommended" way for running OpenStack on kubernetes. Questions like: Should I
run rabbit in a container? Should I put my database in there too? Now with
PetSets it might be possible. Can we be smarter on how we place the services in
the cluster? Or should we go with the traditional controller/compute/storage
architecture.

You may argue that I should just read the yaml files from kolla-kubernetes and
start from there. May be true but that's why I asked if there was something
written already.

Thanks for your email,
Flavio

>Regards
>-steve
>
>
>
>On 9/22/16, 4: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.
>
>    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

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160923/90f1fcad/attachment.pgp>