 Okay, let's get started. Well, first of all, thank you so much for coming. I'm so happy to see so many of you here. And today's topic is a very hot topic. It's very interesting as well. And according to our user survey, container has always been ranked as one of the top three interesting topics for our community. So, and there's still a lot of discussions and a lot of speculations and confusion and I think it would be good to, you know, try to use this section to get some of your answers, your questions answered. And today, I'm very fortunate to have invited this elite panel for you. And we have both business people and technical people where people, you know, we have board directors, we have PTLs. This is a really heavy duty, heavyweight panel. So let me, without further ado, I'd like to introduce this elite panel. So first of all, I'd like to introduce we have two open-stack board directors who also sit on CNC and board directors, Todd and Kanji. And then I'd like to introduce, we have three PTLs or XPTLs who work on container projects in the open-stack community. And first, we have Steve, Steven. And then Adele. And then Nihao. All right. Okay, let's get started. And I do want to leave some time for you to ask questions. And again, like this is gonna be both business focus and technology focus, but not too much detail in technology, but more of on the issue side. Okay, so first of all, we know there's a lot of things happening in the container space, right? Some of it's hype and some of it are true, right? So the two best people to talk about them are the two board directors who sit on both open-stack board and CNCF board. So I'd like to invite Todd and Kanji to share with us what's happening in the container space, the good and bad and ugly. Good and bad and ugly? No, it's all good. Container? Container, yeah. Hey, good morning, everybody. Thanks for coming. Todd, Todd Moore, and I work for IBM, but I helped put together the activities for the CNCF and have done the same in the past for open-stack because we really felt that the container world needed a locus for starting handling the issues that span the different environments that are using containers, whether it was mesos or Kubernetes or Docker, that there were a set of issues. There was a set of common things that we needed to be doing and that there was a new vision that we needed to have for truly cloud-native applications based on containers. So that led us to form the CNCF, but what we realized when we did that was that there was a lot of synergy back with all the other organizations that were going on. In fact, because of my role here at the OpenStack Foundation, it was very natural to start bringing in the OpenStack team to start talking about and sharing what it was that we had and the important aspects and how all of this could play together across the containers. So it became less of a, containers are gonna take over the world to more of a cooperation between organizations that started to form. What we find is that, especially in the CNCF world, is that we don't wanna replicate everything, all the great work that OpenStack had done, all that difficult networking and storage and other activities were just, its security, et cetera, just tremendous amount of effort, years of work put in and to start from scratch and go do that all over again and replicate that just didn't make any sense. So that synergy started to build and people could see that we needed to start working together. And we've extended that thought into places like Cloud Foundry, right? Cloud Foundry at its heart underneath is, of course, containers, right? So we could have a common container specification of the OCI. I think Kenji wants to say a few words about that. And that common container, the RunC container that came out of Docker could be used everywhere, right? So we started forwarding relationships with the Cloud Foundry team as well too. So not only is Docker talking in part of this, but Cloud Foundry is as well. And then in CNCF for this new Cloud vision that we have, we need a common service broker, right? Everybody needs a service broker. It needs to be very good. So now we've spawned a project that we're working on across the Cloud Foundry team and the CNCF team to go build a service broker that we can all go pick up and use and not duplicate. So this theme is continuing and we're starting to see that a world of cooperation is building across the container projects. Now that's not to say that there isn't end fighting and little things going on, right? It's also a hotbed of mine versus yours and other things, right? And people wanting to fork or rumors of fork or other things that go on. So all that is sort of playing itself and people are starting to work together. And our hope here is that the work that we're doing there becomes something that unifies people as opposed to seeing it break apart. And so we'll see a lot more happen in that world. And I think we'll see pieces of really important infrastructure that Docker has been working on and other things start to come out and fill out the portfolio of things that we need to happen. And the CNCF and OpenStack and others will drive that. Great, thanks, Kanji. Hello, my name is Kenji Kanji. I'm in charge of OpenSoft software development team in Fujitsu. Please forgive my poor English. Very good English. Diversity. From my perspective, I have three topics. First three are container related to functionalities and the capability such as Magnum and Clear and the Collab has been actively developing OpenStack. And I personally, I am personally very interested in Collab project which will make OpenStack deployment of much easier because it is a very new use case of container technology in OpenStack in addition to deploying application using container. And the secondary, second is about standardization of the effort of container. The standard runtime and image format is very important to ensure the application portability and sustainability. Those standards are currently actively discussed and developed in OpenContainer Initiative as known as OCI since last December. And first specification will be released soon, I believe. I believe that it will bring our, it will be our value of step of growth of container ecosystem. And last one is about momentum of cloud native computing. In addition to deploying the application using container, it is very important to connect the applications and provide them as a new service. The cloud native computing foundation as known as CNCF hosts various project and is developing a software building blocks for cloud native computing based on microservice architecture. And in addition to that, the standard API is also very important. I believe that standard API and software building blocks provided by CNCF will bring a hyperscale distributed application platform and allow applications work together and create new values. Okay, well I really appreciate in our country and their contribution and being the bridge between OpenStack Foundation and CNCF and OCI. And I really think that OpenStack is an integrated platform and we want to make sure that we welcome all these different various open source communities into our ecosystem. So thank you for your work. And so now next I would like to ask the technical folks the PTLs, the XPTLs, and to kind of talk to us, to everybody about what those three container projects in OpenStack. And I know some of you might know already, but I just want to kind of build a baseline so we all have an understanding of what kind of container work that we have been doing in the OpenStack environment. So Stephen, would you like to start? Sure, I'd be happy to. Okay, that's working nice. So I've really been involved on making sure that containers are brought to OpenStack. That's really where I've focused pretty much the last three years of my life in OpenStack. Got involved in Magnum for most of the original commits and recruited the core team. So I know quite a bit about Magnum. Magnum is a really interesting case in which we run Kubernetes on top of OpenStack. And then kind of at the same time we started COLA. COLA right now is a, it deploys on it with Ansible on bare metal. So it's not really something that fits well with cloud native, although in the future we're going to go to a model of what I would call converged cloud, which is where you run Kubernetes underneath and you run OpenStack on top. So that's where I see the future of those integrations between Magnum and COLA. So they're kind of, they're both models, right? So you've got Kubernetes on top and you've got OpenStack on bottom. That's Magnum. And you've got Kubernetes on bottom and OpenStack on top. That's COLA Kubernetes. So that's, that's COLA and Magnum and the nutshell. So would you like to speak about COLA a bit? Yes, thank you. My name is Mihave Szembski. I work in open source technology center and Intel and PTL in COLA project for OkataCycle. So if you've seen yesterday's keynote, there was, Stephen said there are a couple layers of containers in OpenStack or OpenStack in containers. So according to the recent surveys, deployment of OpenStack is still a big issue and upgrades is still a big issue. And these two are very, very close together. So containers helps both. So it was only natural that at some point we need to create, we need to use this new awesome thing to deploy stuff that containers are. And we did it in COLA and as Stephen said, COLA, we started with, actually yesterday on my presentation, you could see the, we have a couple different trials on how to deploy, how to actually deploy containers. Ansible is the first one that actually worked and it's ready now. I can show you to try it. And I won't actually agree with you, Stephen, that it's not cloud native. It is actually cloud native. It's about applications that are cloud native. It's how you deploy containers. It's a different topic. And if you deploy them with Ansible, they can be just as cloud native. And we wanted to prove that OpenStack as an application services are actually pretty well made cloud native applications. And if you deploy COLA, you can actually see that's true. Well, Gail, would you like to talk about courier? Yes, hi. I'm Gal Sagi. I've spent the last two and a half years working mainly on OpenStack networking and containers networking. Started with Tony project career and the previous PTL of the project. We started the project because what we notice is that users are starting to deploy like Todd mentioned and everyone else containers side by side with OpenStack, whether it's isolated or whether it's the same environment, deploying containers inside OpenStack nested. And today everyone are talking about deploying OpenStack in containers. And what we notice in these environments that there are different set of solutions and drivers and infrastructure for containers and for OpenStack. And we said, why? Like why can't we utilize and use the same infrastructure both for your containers and your OpenStack workloads? And this is what career is all about, bridging between these two worlds. And we started with the networking use case where we now have, where you could use Kubernetes or Docker or Mezos and actually map these models into Neutron. So you could out of the box, any solution that you have that support Neutron API can now also be used for your containers networking, whether they are nested inside VMs or on bare metal. And of course this also expose all of OpenStack richness and flexibility and advance services to your containers. Great. So thank you for that information. And so I just want to say from a user perspective, now we have Corea, Cola, Magnum, and then you'll have OpenStack, we have Container, CNCF, OCI, all these things. So can you guys share with us, with the audience that what are the use cases to, as a user, when should I use OpenStack only? When should I use container platform only? Or when should I use containers on top of OpenStack and or OpenStack on top of Container? Can you just give us use cases from a user perspective who would like to start? Sure. Meow. So well, I think, so if everyone here's, I assume is using OpenStack. OpenStack are virtual machines, virtual machines have its differences between containers. And I would say, if you need to run virtual machines, just use OpenStack. But on that note, to use OpenStack, you need to deploy it. Then you can use Cola to do it, which means you will be using Container. On the other hand, if you run just containers and your whole workload is super cloud native, I'm pretty sure the new container engines like Kubernetes or MISOs will be perfect for you. There is also this use case which Steve mentioned, which probably will be true for a lot of people when you need both. When you need to have different workloads, needs different tool sets. Like certain things will need stability and maturity and security of virtual machines or bare metal. Other workloads will be cloud native, totally cattle like things that could pretty much run on Kubernetes. Then you can deploy Kubernetes cluster across your data center and deploy OpenStack on part of it, using for example, Cola Kubernetes and keep rest of the cluster ready for your cloud native workload. There is one other use case, which actually will use Magnum because I should probably know, containers are not exactly more secure. If you're concerned about security and separation between multi-tenancy, separation between tenants, but still your tenants needs to run cloud native applications, you can make use of the very neat idea that Magnum will pretty much spawn a Kubernetes cluster on top of virtual machines so every tenant you have can have their own private Kubernetes cluster with all the nice things Kubernetes has to offer while being completely secure and separated with the VM level of multi-tenancy from another tenants in your infrastructure. So, I think that's pretty much sums it up. If I can add, during this past two years, I've seen everything like all kind of mix and match configurations and all kinds of setups and environment. And I think like with any other technology, I don't think you want to set any kind of limitations. You need to identify your use case, identify your traffic patterns, identify what you're trying to do and then really investigate what the solution gives you. Don't just because I see a lot of people that are converting things just because there's a lot of talk or hype talking about the specific technology or the other. Try to find out with reliable resource and testing what is best for you and after you've found it, think five years from now what will be the best solution for you and plan for that. Yeah, I was just going to add when I was listening to his use cases and the thing that we're going to see is there's sort of a time horizon of long running things and very short running things. We're seeing the whole serverless world start to rear its head now and lots of uses around containers in that to spin things up very quickly. So it's going to be the spectrum that you have and it's going to depend on what you want to spend for your application as well too, what's the cost structure and behind that do you just need something to spin up quickly and go away and not want to have that whole server sitting there running either a VM or running your containers under VMs or over VMs, et cetera. So this whole spectrum is going to be here and you need to explore that entire space as you build out what become your cloud native app. So there's infrastructure that's now coming together around serverless. There's an open source project that's just starting up at Apache and there you'll be able to go and play and see and participate in that as well too. So look at the whole spectrum and decide what makes sense for your application. Yeah, I would just like to add that again I think the Converge Cloud is a really solid model for larger enterprises. You know, the idea that virtual machines are going to go away is just not going to happen, right? We've got software that's 20, 30 years old so people are just now migrating 10 years after VMs have kind of emerged onto virtual machines. So those applications are not going to be rewritten. Cloud native is more of a greenfield approach, which is great. I like greenfield, I'm kind of a type of the spear engineer myself. So I think that's a very unique feature. I think we want to make sure that OpenStack and CNCF work well together. And I think the projects we have today that we've identified kind of early on deliver on that model, there's probably more we can do. Where we kind of cross over in the future is undefined. I think it's kind of depends on who's willing to lead the projects and that's really what it comes down to. As far as the Converge Cloud that's going to be tackled and that's more for larger enterprises whereas maybe to your question of whether or not where would you use these things I think OpenStack might make sense in a smaller enterprise 100 nodes or less if you wanted the larger enterprise you might want a thousand nodes of Kubernetes and you might want 500 nodes of OpenStack. And you'd want that all on one platform. You wouldn't want two things to maintain because operators hate that and it increases operational expense and that's a big problem for operators. So we know that you know like you said it's going to be a converged hybrid with container bare metal and VM. So do you think that what we have today with all these three container projects Kola, Korea, Magnum any need for other container related projects in OpenStack if there is what do you think should like we should be thinking about. Okay anybody? I know I never asked you guys this question so sure. I can say I'm not sure about any new project but and this is something that we try to do last summit in the operators summit and it's very important for us the people that are building the solutions and are driving these projects to understand the challenges and the problems better. So I do believe that we need better collaboration first of course between the communities containers and OpenStack but also between us and the people that are actually deploying and actually using these capabilities to understand what is the priority what needs to be addressed and what are the difficulties of running containers on OpenStack side by side. Actually I do have an idea for a new project. I may not start myself because I've done that plenty of times and it's very painful but Todd mentioned OpenWisk I think OpenWisk is fantastic in terms of providing serverless serverless is a new thing you know there's a machine learning that would be a new thing serverless is really interesting and OpenWisk is really interesting going into the Apache Foundation maybe there's some opportunity to figure out how to get OpenWisk to work inside of an OpenStack ecosystem that I think that would be really compelling to people because I see serverless as kind of the next big disrupter in technology. Anybody else want to add? No I like that I think that's true and the more that we as a community reach out and work with the other nascent projects as things come involved in this space and make them part of the community and the ecosystem that we have and are friendly the better this is going to come out so keep that in mind and I think that's just a great suggestion I just want to add that there is some initiatives for Amazon Lambda like for for Swift and I wanted to say that Docker was the first one that deployed container image based there's emerging project Rocket which may also find its way into pretty much any all the projects that we just mentioned there are Docker centric today Kubernetes is moving more towards Rocket so Rocket can be next next thing that people may want to look at and make sure that projects that works currently will work with Rocket and other container engines just as well or pretty much what we think need most now today is not as much as new projects as to ensure that projects that are there today are major are stable and are well tested because container are still new in operators mindset and operators are not very trusting trusting folk because they have reasons not to trust the new thing which means we need to make sure that containers will reach the level of maturity when actually people would deploy it without having to fear for their life and I think that's the biggest challenge today in deployment so fear for their life they are more cautious because they are all about carrier grade exactly that's the thing and I bet nobody here will say that container are carrier grade today so I just argue with that a little bit I think containers at least as we use of them in COLA today are very rock solid and I think as Kerr uses them when we did our Kerr integration with COLA that's rock solid I think Magnum the container implementation there very rock solid you know some of the newer features of Docker that those things may not be rock solid so but everything that is in open sector today is rock solid and I don't think operators should be concerned with those things I would bet my date on it so what I'm saying essentially what I'm saying essentially is container is still new and they need to be there for time you mentioned Docker is not rock solid if Docker is not rock solid then we then we need to make it rock solid that's essentially what I meant okay yeah I agree with that but I think it is 112 maybe wasn't as stable because of some of the things they did it sort of last minute but I think that over time that's going to get better too of course time at work is what we need but containers have been around for a really long time actually I mean Alexi is there for 20 or so years now yes I'm glad I have Mihao and Stevens standing far apart from each other we beat each other up later but then they bond in the container space so I can see that some people my thing is very mature some people I don't even know still new so from a user perspective like you said operators or user perspective if they want to adopt container if they are already using VM open stack if they want to adopt container what's your advice on how they can get in there with certain peace of mind and safety and adopt container in the open stack environment in a more of a safer way who would like to address that I'll take a crack at it you have to train on container technology it's not something it's just like training on open stack it's not like you get open stack and then you're good to go even though with Kola you can deploy 120 nodes in 20 minutes you don't know how to use open stack after you deploy it we can deploy it really easily but we don't know how to use it well I know how to use it but not everybody knows how to use it containers are the same state except they're newer so there's less people that have experience with containers so I think if you want to learn how to use containers training is a good way to go and the best way to train in my opinion is on the job training you can use it with containers see how containers work again I think looking at open list would be interesting from a kind of where the future is going to be maybe a couple years down the road that's a totally different programming model than even containers even though it uses containers it's an implementation detail so those sorts of things are things to train on I don't mean training by professional trainers I mean training by doing real work and partner with people who understand the technology and part of it and do POCs and other things to get those who can transfer some knowledge into you working with you and don't be afraid to ask there's plenty in the community as well to talk to people here obviously want to share we're here at summits but find a friend when you hear make a friend who knows something about containers and share and next summit come to get together as well too and keep moving it do you think there's a room for us to create reference architecture or any kind of cookbooks or any kind of tips stuff that in the repository that people can kind of get a kickstart those things are coming here and the foundation is working towards that so we're using all of the open-sec infrastructure but not using NOVA and using Kubernetes with that infrastructure we see that in the survey results so us being able to then develop a reference architecture around that and help other people understand that is something that we think we'll want to go and do we had a good session with the analysts and this very same question came up we're going to work through that and we'll provide those things and we'll provide that information about the different architectures that we have I'm glad to hear that so I just wanted to add that when I said that containers are still early in the game at least in open-stack deployment field you're much better with them than without them so regardless to what I said before just try it and see what's the difference what's the actual issues there are issues, there will be issues in the last years but you'll still be better off with them so I think it's work to just try and play with it and see whether or not it meets your needs great so I have a few minutes left and I'd like to open up to the audience for questions could somebody give her a mic I probably don't need a mic you need to be recorded everything has to be recorded thank you everyone on the panel I have a question about I missed a session this morning on Zoom that used to be called Higgins apparently and it's saying it's a new project in open-stack and that Magnum's moved to just supporting container orchestration engines can you tell me how Zoom fits in yeah so I can answer that question a little bit basically Magnum started out with an API that allowed an abstraction over Kubernetes APIs and Zoom took that abstraction part and provided it separately now Zoom's not in the big tent it's kind of a new emerging project we'll see how that works out I think the early feedback we got when we did develop Magnum was that people wanted to use the native tools provided by Google and Docker for the clients they didn't want to use an abstraction that's my general take on the situation but Zoom still I think serves a purpose and I think people will be interested in it once it joins big tent so to Steven's point what Magnum really does today is they deploy Kubernetes and with Kubernetes you can deploy whatever what Zoom does is to kind of deploy Docker without the Kubernetes in between, just use Nova to it so there was a driver called Nova Alexi Nova Docker and that's pretty much the next generation of this the native clients are the big thing now next question thank you for the presentation you say please test, please play with what about the other way when as a cloud provider I must deliver the cloud, I must ensure the production grade so what do you think about the new way of using or administrating the open site layer or a cloud native application to the cloud to the cloud to the cloud to the cloud it's not the same tooling to monitor to administrate the application and to react can I ask a follow-up question do you mean open stack specific or could be open stack specific then at caller level what's the impact of the package in caller if you take an unseable version of callable deployment caller it's a glorified package we just build the packages before we install them we build images and then we just push them to the nodes there is very little impact on the things like monitoring like logging in fact in caller itself we already have deployment stack we have demo deployment of the monitoring stack but if you want to hook it up to your own set of toolset everything's possible it may require you to do some thinking we're more than happy to help you but the runtime of the container in effect is not that much different than the runtime of the classical application and as I said if you try it there are many many benefits from using containers and it's worth it to add this some level of complexity because the benefits are significant good so if we're just talking about colon and open stack on top of a container environment there's 12 APIs that we use to operate an open stack deployment only 12 APIs so it's very simple and if you're using something like Docker you know there's I don't know 60 or 70 APIs plus a whole bunch of variables sorry not variables but big options and whatnot so it depends on what your use case is so that's why I asked the follow up question if you were more interested in open stack or more interested in containers because containers are not as easy to use today that'll change to use today as for example cola is but cola we really focused on operator experience that's like our mission pretty much we want our operators to have a good experience so 12 APIs we want to keep it nice and simple so people can keep it in their head and understand it so is anybody have anything to add? no that's okay thank you any more question what's the opportunity that we get all these experts on stage was there actually there's a mic here if anybody wants to keep it we have one question here thanks so you said that basically horses for courses with regards to application deployment paradigms you could go open stack, you could go serverless you could go somewhere in between if you look forward five years we have a fraction that's deploying by each of those paradigms predict the future for me that's a good question I know it's a tough one yeah I'd like to guess but I don't really have any idea so you have an idea so all these things evolve over time if you look right now you'll see that VMs dominate the world and containers are coming and people are trying to put into production most of these things take on a time horizon five, ten years to really become solid and become part of the infrastructure so I think that most obviously it's a sliding skill that's going to happen here and I think the serverless world is probably ten years out I think with some large fractions say 25% of what's going on there are more if the cost model works out in latency issues and other things I'd say that in the five year horizon containers are going to take a very large chunk of what's going on 30-40% of what we do will be there but I think that in that time horizon you're still going to see VMs substantially be what they are today and it's not just KBM or it's VMware and other things are still prevalent and will be for a long time thanks Tom for rescuing me yeah well I think we just ran out of time well thank you so much audience and thank you so much panelists and it was a good job thank you