Here you go Flavio, Sergey and team collected some information from fuel-ccp efforts.
Design for OpenStack Containerized Control Plane : https://review.openstack.org/#/c/378266/ Design document for clustering services on k8s : https://review.openstack.org/#/c/378244/ Add test plan/results for fuel-ccp : https://review.openstack.org/#/c/378271/ Thanks, Dims On Tue, Sep 27, 2016 at 4:23 AM, Flavio Percoco <fla...@redhat.com> wrote: > On 27/09/16 00:41 +0000, Fox, Kevin M wrote: >> >> I think some of the disconnect here is a potential misunderstanding about >> what kolla-kubernetes is.... >> >> Ultimately, to me, kolla-kubernetes is a database of architecture bits to >> successfully deploy and manage OpenStack on k8s. Its building blocks. Pretty >> much what you asked for. >> >> There are a bunch of ways of building openstacks. There is no one true >> way. It really depends on what the operator wants the cloud to do. Is a >> daemonset or a petset the best way to deploy a cinder volume pod in k8s? The >> answer is, it depends. (We have an example where one or the other is better >> now) >> >> kolla-kubernetes is taking the building block approach. It takes a bit of >> information in from the operator or other tool, along with their main >> openstack configs, and generates k8s templates that are optimized for that >> case. >> >> Who builds the configs, who tells it when to build what templates, and in >> what order they are started is a separate thing. >> >> You should be able to do a 'kollakube template pod nova-api' and just see >> what it thinks is best. >> >> If you want a nice set of documents, it should be easy to loop across them >> and dump them to html. >> >> I think doing them in a machine readable way rather then a document makes >> much more sense, as it can be reused in multiple projects such as tripleo, >> fuel, and others and we all can share a common database. We're trying to >> build a community around this database. >> >> Asking to basically make a new project, that does just a human only >> readable version of the same database seems like a lot of work, with many >> fewer useful outcomes. > > > I just want to point out that I'm not asking anyone to make a new project > and > that my intention is to collect info from other projects too, not just > kolla-kubernetes. This is a pure documentation effort. I understand you > don't > think this is useful and I appreciate your feedback. > > Flavio > > >> Please help the community make a great machine and human readable >> reference architecture system by contributing to the kolla-kubernetes >> project. There are plenty of opportunity to help out. >> >> Maybe making some tools to make the data contained in the database more >> human friendly would suit your interests? Maybe a nice web frontend that >> asks a few questions and renders templates out in nice human friendly ways? >> >> Thanks, >> Kevin >> ________________________________________ >> From: Flavio Percoco [fla...@redhat.com] >> Sent: Monday, September 26, 2016 9:42 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture >> to deploy OpenStack on k8s >> >> On 23/09/16 17:47 +0000, Steven Dake (stdake) wrote: >>> >>> 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. >> >> >> Steve, >> >> Thanks for getting back on this. Unfortunatelly, I think you keep missing >> my >> point and my goal. >> >> I'd like to document the architectural choices and see if there's a common >> ground in which different teams can collaborate on. In addition to this, >> we'll >> also see at what point these teams will start diverging in architectural >> choices. Will the time invested on this be entirely wasted? Maybe. >> >> I'm failing to see what is wrong about my request. You mention that I need >> to >> contribute to have my voice heard in Kolla as if I'm trying to change >> anything >> in it. Spoiler alert: I'm not. >> >> I'd like to first work on what I've mentioned in my email and then take >> the next >> step. It's also important to note that I've not asked the Kolla team to do >> this >> themselves. I've said that I'd like to hear thoughts and friendly >> discussions on >> this from different teams (not just kolla), which could easily happen over >> email. For example, we could stop arguing whether my email makes sense or >> not >> and perhaps start dropping some ideas here. >> >> Anyway, I appreciate your input and you taking the time to explain the >> status >> and efforts of the Kolla team. As far as my contributions go, this is a >> way for >> me to start contributing on the deployment on containers efforts around >> the >> community and more specifically on the kubernetes side. It might not be >> what >> everyone wants but I believe it does help and it'll create a common place >> for >> collaboration on this topic amongts different communities (including OPs). >> >> Flavio >> >>> 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 <fla...@redhat.com> >>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >>> <openstack-dev@lists.openstack.org> >>> Date: Friday, September 23, 2016 at 3:10 AM >>> To: "OpenStack Development Mailing List (not for usage questions)" >>> <openstack-dev@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" >>> <fla...@redhat.com<mailto:fla...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> -- >>> @flaper87 >>> Flavio Percoco >>> >> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> -- >> @flaper87 >> Flavio Percoco >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > @flaper87 > Flavio Percoco > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev