Open Stack

Responses inline.

From: Sergey Lukjanov <slukjanov at mirantis.com<mailto:slukjanov at mirantis.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Friday, April 22, 2016 at 11:17 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes

Hi folks,

I’ve been approached by multiple people asking questions about what is happening with Mirantis engineers activity around the kolla-mesos project we started and I do feel that I owe an explanation to the community.

Indeed during the last few months we significantly reduced the amount of contribution. Jumping straight to the point, I would like to say right away that we will have to abandon the kolla-mesos initiative. If anybody would like to pick it up and continue moving forward, Mirantis will do everything we can to help with the ownership transition including sharing what we learned along the way.

Thank you for your contributions thus far.  The work of Eric relating to diagnostics has been especially helpful to Kolla's mission to provide production ready containers and deployment tools for operating OpenStack clouds.  An OpenStack cloud is pretty difficult to operate without diagnostics, and Eric's impact has been dramatic.


Now please let me explain the reasons behind this decision which I hope will turn into an active discussion in the OpenStack community. When we started work on the containerization of OpenStack we did not have a clear picture of the design choices and decisions that would need to be made. What we knew there is a community project around the effort - Kolla, and we decided to try and explore the opportunity to join these efforts.

First let me express my gratitude towards the Kolla community for their willingness to help and support our efforts. The way the Kolla project accepted and helped new people join the project is one of the fundamental behaviours that makes me really proud to be a part of the OpenStack community.

During the journey working in Kolla, we discovered that there are quite a few fundamental mismatches between where we believe we need to arrive running OpenStack containers inside orchestration framework like Mesos and Kubernetes and the Kolla direction of running containers using Ansible. While there is nothing wrong with either approach, there are some technical difficulties which lead to conflicting requirements, for example:

* Containers definition should be easy readable and maintainable, it should provide meta information such as list of the packages to be installed in the container, etc (container image building DSL is one of the options to implement it);


Trying to understand the issue here, do you believe the current jinja2 Dockerfiles are not readable?  I'm pretty sure my 11 and 13 year old children which are just learning programming already understand conditionals and variables.  A full-blown DSL for describing container contents seems out of the domain of Kolla's mission, although I'd never say no if someone wanted to give a crack at implementing one.


* It should be possible to implement containers layering, naming and versioning in a way to support upgradability and patching, especially in terms of shipping security updates and upgrades to the users;

Mitaka Kolla implements upgrades without problem, atleast in the Ansible orchestration code path.  Upgrades work fantastically, and it is one of the motivations I had for founding the Kolla project.  I don't see the problem with having kolla version 1.1.0 upgrade to 2.0.0 when the containers are tagged as 1.1.0 and 2.0.0 but I'd love to hear more feedback.  If the problem is we need an alpha, I agree, we need x.y.z.a where a represents a vendor's specific container version set.  Could you expand on precisely what you think the problem is?

* Containers implementation should be clear from the bootstrap and init scripts;

This is a little more difficult to achieve mainly because of the requirements of needing to drop root privileges.  Still I'm struggling to understand what is super difficult that a typical engineer coming out of university couldn’t grasp about the container booting process in Kolla.  I'd love to hear your feedback on this point.

* Repository per OpenStack and Infra component, e.g. one from nova, one for neutron and etc. - to contain all needed container images for running corresponding services in different topologies;
* It should be possible to use other containers, not just docker, for example - rkt.

I disagree strongly with the solution.  But you have stated a solution without a problem.  I can tell you why I am anti-mult-repository – it makes managing backports very difficult and time consuming.  It makes repository management very difficult.  One error I think we made in kolla-mesos was making a separate repository in the first place.  The code should have just went straight into the kolla repo under the mesos subdirectory just as ansible is today.


Since we believed Kolla would likely have to change direction to support what we needed but we still were not sure in the exact technical direction needed to take, Mirantis decided to take a pause to prevent unnecessary churn to project and run a number of research initiative to experiment with different concepts.

Understood you needed to take a timeout to understand your options.  I hope timeout doesn't turn into "running out the clock". :)


While the above work was happening, Mirantis was also tracking how the Kubernetes project and community were developing. We were very glad to see significant progress made over a short period of time and community momentum build similar to how OpenStack grew in the early days. As part of our exploration activities we decided to give Kubernetes a try to see if we could make containerized OpenStack work on Kubernetes and better understand what changes to OpenStack itself would be needed to best support this approach.

At this point I’m glad to announce that I was able to do a very simple PoC (~1.5 weeks) with the core OpenStack control plane services running on top of Kubernetes. I’ve recorded a demo showing how it’s working [1].

I watched your video.  Looks interesting.  I've struggled a bit personally to understand what value an underlay has over bare metal, but perhaps there is some.  There certainly seems to be some, especially from our core reviewers who asked me to modify the schedule for Austin.  The result of that schedule modification is here:

https://www.openstack.org/summit/austin-2016/summit-schedule/events/9157


Based on our research activities and rapid growth of the Kubernetes community, which shares many parallels to the OpenStack community, we are switching our efforts to focus on running OpenStack on Kubernetes. We are going to do the development work upstream and as part of that share and contribute results of prototyping and research work we have done so far.

We are considering multiple options on what is the right place in community for this work to happen: re-join the work with the Kolla project, start a new project or explore whether it would fit into one of OpenStack deployment projects, like Fuel.

Makes sense to me to stick with Kolla considering you already have core reviewers under Mirantis employ who have relationships with other Operators, Developers, and Core Reviewers in the OpenStack in containers community.

Hope to see you in our design sessions, and again, thanks for the contributions thus far.

Regards
-steve


I’m going to have a conversation with Kolla and Fuel teams during the summit and will keep the community posted on the progress.

[1] https://youtu.be/lUZuzrvlZrg

P.S. Kudos to Sergey Reshetnyak and other folks for helping me preparing demo.

--
Sincerely yours,
Sergey Lukjanov
Principal Software Engineer
Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160423/2a1a2030/attachment.html>