 Hi Antoni, I am Krishnagaram from Intel Corporation. I am representing the OpenStack Foundation's product working group and this is part of a series of video interviews for the Newton design cycle. So where we are interviewing each of the project leads or course to provide some details about what is being planned for the Newton release coming up in October before the Barcelona Summit. So to start with tell us a little bit about yourself and what you do. Very well, thanks. So my name is Antoni Saurepuimeton. I work at Midakura and I've been a core of the Kure projects since the very beginning. We started with Cal and we quickly got more people involved and I tend to take care of the aspects of the project that are more about planning the features and bothering a bit the people around about we should add this, we should add that. So that's more or less what I'm doing. I wouldn't call it product management because it's not really a product but it's just taking care of the small nuisances and the path to grow. Okay, excellent. Thank you. Thank you for that. So tell us a little bit about the project, the Kureer project which I know is based on a Czech word for the English word Kureer. So tell us a little bit about it. Yeah, so the project just like a Kureer is to bring packets, in this case networking packets to a destination and the destination is the container world. We started simply with LibNetwork driver and for those unaware, LibNetwork is the Docker implementation of the container network model. Yeah, because there's competing standards and always get them mixed up a bit. So we started with that and the idea is that in the container networking world, the things are very simple. They are not production ready or they don't give you the features that one would expect from networking software like what you get in Neutron from the different vendors and so on. So we set ourselves to bring all the Neutron power to the different container solutions. So we started with Docker. We made target rocket at some point. It was discussed in the summit. We are now working on other orchestration engines like not just swarm with LibNetwork but also Kubernetes. So we are interpreting all the good of the networking that is in OpenStack to as many container projects as possible. Terrific. And you mentioned the Austin summit. So what were the hot topics there? If you could summarize two or three hot topics during the Neutron design summit. Sure. So we are right there with something that was already working which was the LibNetwork integration. And we also brought a surprise for the presentation which was well, for one of the presentations which was to show how the fact that you have Neutron backing your networking doesn't just let you connect your containers and your ritual machines but it also allows you to bridge the gap between competing container technologies. And in this case we showed how I could ping from Kubernetes to swarm containers. Okay. And that was a prototype, the Kubernetes, which we are starting to upstream now. So at the Austin summit, the biggest focus was satisfying the different use cases that the operators have now when they want to operate containers because nobody runs just Docker. The focus was to provide the networking for swarm to design and stabilize the prototype that we have for Kubernetes, start to plan a bit what to do about the mesos integration and also how to do all of that in when containers run inside virtual machines like the Magnum project does. So we had some very healthy discussion with the Magnum team into how a first integration can look like to bring the benefits that we can bring there to have a native open stack networking for containers that are managed by Magnum environments. Right. In fact, you talked a little bit already about user needs, specifically that nobody operates a container environment in isolation. It has to interface with your existing networking environment. And you also talked about integrating with the Magnum project. So were there any other user needs that you were identified or problems that you're looking to solve? Sure. Sure. We're also growing a bit in scope. There are teams in open stack that are starting to form to bring things like block storage, disaster recovery and all those things to open stack and to containers. And in the way that they want to do that, we are trying to help and to be a bit of an incubator for those projects. So that's also something that is in the scope, because for me and for us in Kudir, the value of open stack is not just an environment where you run virtualization workloads, but it's more of a set of APIs that you can use for providing advanced and production ready services to whatever you have to bear metal to containers and to virtual machines. And the good thing is that if you use these APIs for all of your workloads, your operators will be able to leverage the knowledge that they often they have for across the board and also to lock everything on the same way, to have the same policies and the way that we want to do that, because that is very important for operators, and it is a big need is that it has to feel native to the platform, but still allow you to go behind the container orchestration and tweak things in Neutron or in Cinder or whatever. Right. So as I can see, this would also eliminate the need to do a lot of individual modules in Magnum to connect the different types of environments to the networking, right? It's all being done through one standard set of APIs. Yeah, exactly. It would be shifting a bit the work. So Magnum would still need slightly different Kudir deployment for each of the container options, but it moves the work of accommodating those networking requirements for each of the platforms into the Kudir project. Yeah, and that's why we started now to split the repository into a core library that we use, which was the original repository, and then we'll have one for Kubernetes. Well, we already have that one, Kudir Kubernetes. We have Kudir Live Network, and we will have others, I guess. Okay. So then what would you say are the top three priorities for the Neutron release, right? If you're really narrowed down to, okay, we've got all these things you're going to do for Neutron, what would you really prioritize? Sure. So in the Neutron cycle, the biggest focus is going to be in having this split of the repositories, so that we are able to build a proper pipeline for delivery of our solution. So with each commit that will go into Kudir Live Network, for example, it will automatically generate a container that will figure a job that will run the Kudir container with the Neutron and Kiston containers out of the project cola. It's going to run end to end testing with that with Docker Swarm. And we're going to have something that works is reliable. And also, we can tack as a first release of the Live Network driver of Kudir. And then we're going to have to do the same for Kubernetes. It's not going to fit all in the same cycle, but the approach is the same. With each patch, you run a whole CI that has container as the delivery method. We are not centered so much in PyPy or PyPy like other projects. Our chosen way of delivery is through containers. So what we want is that people can just do Docker run. And they already have Kudir and they can point it to their existing Neutron or they can just use cola to spin out to spin up, sorry, Neutron and Kiston containers. And the final thing that we're going to target is the nested integration. Right. So that we can serve Magnum that needs a still a bit of work in Neutron. And we're going to try to assist and to make sure that the requirements are in line with what both it's probably one of the first collaborations across the team, like it's going to be Neutron Kudir and Magnum. So it may be a bit difficult, but if it works, I think it's going to provide a lot of value to open stack operators. Okay, from what I hear your whole description of your priorities for Neutron, it seems like interoperability is a big theme for the Neutron cycle. And maybe a little bit of modularity. Are there any other themes that you have? Yeah, well, the biggest one is that by we are trying to solve different things in this way of the container delivery that passes a pipeline of tests, using the containers and so on. The biggest late motive behind that is that we want something that is easily repeatable, and that has been tested in the way that it will be consumed. So I expect people that they maybe they will adapt the containers that we make. But our containers should have much stronger test testing than they have now. And we should build a bit of tooling for the operators so that concerns about where will the logs go? How if you run containers in VMs in Magnum? How will the operators get the data that is running with Asians on those VMs? And so on. So we need to make a good user story for the for the operators that makes everything easy to consume. Yeah, so better manageability. Better manageability and and you know, reliability. Yeah, okay. That seems to fit in. So yeah, you've given us a lot. You've really talked a lot about what's going to be done in Korea for Newton cycle in a very short period of time. Is there anything else you'd like to add? Before we close out the interview? Well, I always like to close saying that if anybody is watching, and he has some requirements that or wants to help with documentation, or he's just going to say, Hey, I ran this specific container orchestration engine, which is not targeted at the moment. But I would like to contribute to that. Even if it just helping design a future integration. Right. Just join us in open stack dash career in IRC or on the mailing list. And we're more than happy to host any crazy integration that you can think of. Right. Okay. That is a very good closing and turning and thank you very much for your time. Really appreciate it. And all the best to the Korea project. We're looking forward to all the good things coming out of the Newton release.