Open Stack

There's a bit of why documentation here (though somewhat dated now):
https://review.openstack.org/#/c/361186/

And here:
https://github.com/openstack/kolla-kubernetes/blob/master/specs/ansible-deployment.rst

But there is still a bunch of stuff that we're still figuring out via the review process.

We've got an opinion on how to do 0 downtime minor rolling upgrades of api services fully automated by kubernetes, for example. Is our solution the best way? who knows. But its the best way we can think of currently. The only way to really gain this knowledge right now is to review stuff as we all come to a common understanding about the "best way". I'm guessing in a number of months, when we have the majority of openstack services working smoothly we will have enough knowledge to really document it well. We only currently have the compute kit stuff working well. For now, we can only revise our best practices as we find new issues when we add new services.

Please do join us and lets work together to find the best solution for openstack on kubernetes. We all want that.

One other thing.

We've been trying to keep workfow/config generation separate from the parts that generate the templates and hand them over to kubernetes. This means, that you can use something other then ansible to generate the config and step through/orchestrate the deployment. not all of the templates are 100% doing this yet, but we're actively working on it.

So, if you wanted to do config management and worflow in say, mistral and/or heat it should work. I think it would fit very well with TripleO's current architecture. We designed kolla-kubernetes here to be flexible to these sorts of needs. I'd also be happy to talk more about this if you'd like.

Thanks,
Kevin


________________________________
From: Steven Dake (stdake) [stdake at cisco.com]
Sent: Friday, September 23, 2016 10:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

Flavio,

Forgive the top post and lack of responding inline – I am dealing with lookout 2016 which apparently has a bug here [0].

Your question:

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.
Your question ^

My answer:
I think what you are really after is why kolla-kubernetes has made the choices we have made.  I would not argue that reading the code would answer that question because it does not.  Instead it answers how those choices were implemented.

You are mistaken in thinking that contributing to kolla-kubernetes won’t give you what you really want.  Participation in the Kolla community will answer for you *why* choices were made as they were.  Many choices are left unanswered as of yet and Red Hat can make a big impact in the future of the decision making about *why*.  You have to participate to have your voice heard.  If you are expecting the Kolla team to write a bunch of documentation to explain *why* we have made the choices we have, we frankly don’t have time for that.  Ryan and Michal may promise it with architecture diagrams and other forms of incomplete documentation, but that won’t provide you a holistic view of *why* and is wasted efforts on their part (no offense Michal and Ryan – I think it’s a worthy goal.  The timing for such a request is terrible and I don’t want to derail the team into endless discussions about the best way to do things).

The best way to do things is sorted out via the gerrit review process using the standard OpenStack workflow through an open development process.

Flavio,

Consider this an invitation to come join us – we want Red Hat’s participation.

Regards
-steve


[0]  http://answers.microsoft.com/en-us/msoffice/forum/msoffice_outlook-mso_mac/outlook-for-mac-2016-replying-inline-with-html-no/298b830e-11ea-416c-b951-918d8f9562cb

From: Flavio Percoco <flavio at redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Friday, September 23, 2016 at 3:10 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

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<mailto: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<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
@flaper87
Flavio Percoco

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