 Good morning OpenStack community, please welcome Chief Operating Officer OpenStack Foundation, Mark Collier. Arigato gozaimasu. Thank you and welcome to day two of the OpenStack Summit here in Tokyo. First, I actually wanted to thank Akihiro Hasegawa for spending the last three years trying to teach me that one phrase in Japanese. And either I'm a slow learner or he's really patient or both, I don't know. Domo arigato gozaimasu. Speaking of interpretation, we do have headsets and Channel One will be interpreting today's talks into Japanese. Channel Three will be into Chinese and Channel Four will be in Korean. So I wanted to kick things off today by telling you a quick story. And I just have so much amazing, such an amazing time at these OpenStack summits. And I don't know what all of you love about them, but for me, it's about meeting people, meeting new people, learning where they're from, learning why they're excited about OpenStack, what they're doing with it. And I had an experience like that on Monday, right after we started to kind of kick things off here in Tokyo. And I was fortunate enough to be able to attend the Women of OpenStack event on Monday night. The Women of OpenStack is an amazing organization. It's helping bring more women into the OpenStack community. So I got on the bus and I was with Heidi Bretz who, if you don't know her, she leads business development for the OpenStack Foundation. She probably knows at least one person at every company here. And so I thought, okay, I love to meet people. This is a good opportunity. So she immediately starts introducing me to people on the whole bus. If you know Heidi, that's not a surprise. So she introduces me to someone from Accenture named Denise. I don't know if she's here today, but Denise works at Accenture and if you're familiar with Accenture at all, they are a very large company and they are doing a lot of interesting stuff to help companies embrace cloud computing. So when I met Denise, of course I wanted to know more about what they're doing with OpenStack. And so she told me a story about how one of her goals was to educate more people on OpenStack within Accenture. And so she set up a conference call to invite anyone within Accenture, just the employees, to dial in and learn a little bit more about OpenStack. And so of course I asked her, because much like my friend and colleague, Allison Price, I love data, I asked her, how many people dialed into this conference call? Because this sounds like a great start to spreading the word about OpenStack. And she told me that 9,000 people joined that conference call. I'm like, you've got to be kidding me. So I don't have a slide on that because that happened on Monday. But you know, this is to me what OpenStack summits all about, meeting new people. And if you meet somebody really cool this week or learn about somebody's awesome OpenStack story, then I would encourage you to just tweet me, tell me about it. And if you want to really level up, you can include the hashtag we are OpenStack, which we're using a lot this week to talk about all the amazing stories about people from different parts of the world getting involved in OpenStack. So I hope that's part of your experience while you're here this week. Now, I did promise my boss, Jonathan, I would talk about the software for part of this. So here we go. The Liberty Release, I imagine you're all familiar by now, is our 12th release of OpenStack. Now, you know, we had a new way of organizing and talking about the many projects in OpenStack this cycle. And Jonathan Bryce talked about it a little bit yesterday. So if you look across all of these projects, one of the things we've done to try to help users understand this world a little bit better, is we've talked about the core services that we find in almost every OpenStack cloud. And we really look at that data, because I love data. And outside of that, there are many really interesting options that are right for some users, for some applications, some use cases, but not for everybody. And that's sometimes called the big tent. And that's even expanding already. I mean, this is unleashing more and more innovation in the OpenStack community, but at the same time built on that solid foundation. And even in the networking world, you can see a couple of interesting examples. Astara is a new SDN controller. It just became part of the big tent. And Courier, I'm not going to tell you too much about because I've got a special guest who's going to tell us all about Courier here in a few minutes. But because I love data and I wanted to analyze all the projects that were in development in the Liberty cycle, I took a look at the activity, all that development work going in, and I wondered what is the most active project in the Liberty cycle, the one that had the most development activity. And I wanted to see what you all think about that, see if we can come up with a consensus. Does anybody have a guess? Cloud kitty. Cloud kitty, probably not, but it's up and coming, it's up and coming. Any others? Nova? Neutron? So... Docs? Well, that's a good point. And gentle, everyone. Alright, well, because I want you all to get the right answer, I've decided to include a hint here. So it starts with an N, hopefully that makes it obvious. So if you guessed Nova, I'm sorry, you're wrong. For the first time in the history of OpenStack, Neutron was the most active project in all of OpenStack. So that's pretty incredible. And I think that's a great sign that there's investment from many different companies and passion and time from many different developers. But ultimately, we want to see what that all produces in terms of results. I mean, the one thing that's, I think, more important than actions and activity is results. And so, you know, we want to make sure that it's not just filled with sound and fury signifying nothing. So we wanted to look at the data and see what do users think, what are users doing with Neutron. So I look back at some user survey data. So we survey the OpenStack users twice a year. So one year ago, of all the OpenStack clouds in production, 68% were running Neutron. Now, that might sound pretty good. No, it's more than half. But the reality is that when this OpenStack networking project started, we all thought by 2014 every OpenStack cloud would be running Neutron. I mean, that was the goal and I believed it. I said it. I was wrong. It didn't happen. And in fact, just a year ago, there was a lot of angst about Neutron. Is it ever going to be the right solution for networking for our users? The old Nova Network style was still very widely deployed. And so when I looked at the recent user survey data that we just calculated, combined, and curated here this week in the past couple of weeks, we found something that was really, really encouraging, which shows that we actually delivered results with all this activity. So we're now seeing that 89% almost every single OpenStack cloud in production is now running Neutron. That's pretty incredible in just one year. And for the other 11% of you that haven't upgraded yet, we do know who you are. And we will be following up. We are going to help. We are going to help you. We are going to help you upgrade this week. And I think that if you really add all this up and think about what's happened in just one year of really, really concerted effort from a lot of passionate people, I think you'll agree that Neutron has finally taken the quantum leap. Tough crowd. Okay. So this is also an American television show that most of you have probably never heard of, but I couldn't resist Scott Bakula. But reality is, you know, all of this is due to the hard work of hundreds of developers. And so I wanted to ask anyone here who contributed in the Liberty Cycle, the Neutron to stand up. Come on. I know you're out there. Amazing. Amazing. All right. Now, there is just one catch. I'm going to need you to upgrade those other 11% of people because I kind of promised we were going to help them out. So, why is networking so hot right now? I think it really is an inevitable shift in the focus of development and the market. You know, and you think about the fundamentals of cloud computing, compute storage and networking, storage and compute. You know, there's still a lot of interesting activity going on there, but they're really matured faster than networking. Networking is very complicated, very difficult to automate. And I think what we're seeing is the time is now for networking to have its day. You know, people are finally ready to get serious about software defined networking. And of course, as you all know, being in the technology business, it has to have an acronym for anyone to take it seriously or to mock it. Two sides of the same coin. But if you look at the SDN market, what's really amazing is these aren't just projections that are going out in the future that someone optimistically put on a chart. This is actually real data from the last several years that shows that the SDN market is growing twice as fast as server virtualization. Now, obviously server virtualization isn't going away, it's just simply the default. But there are some that are estimating that this SDN market will be a $10 billion market by 2018, which to put that into perspective is over 120 billion yen. So it's quite a lot. And just to dive into one specific example, one market that is really right for disruption. There's a lot of investment. It's something called NFV. We'll be hearing a lot about this later today from people that are very close to this massive transformation happening. But it stands for network functions virtualization. And as you might guess, they're going to virtualize the network functions. So I think it was a good name. But what it really means is completely changing the way that telco carriers handle traffic, handle the data that powers all of our cell phones that all of you are tweeting at me from right now. In the old world, to send an SMS message, the carriers had tons of very expensive proprietary hardware in their data center to route those packets, if you will, to where they needed to go. And to go from 3G to 4G, huge time and expense to make that kind of transition because you had to rip and replace all this hardware. And so as I think we've all heard many times, software is eating the world and it is absolutely going to be, I think, as disruptive in the telco world as in any other industry. This is a trillion-dollar industry, the telco market in terms of mobile carriers and beyond. And so the reason that people are embracing software, and this is some data from a recent analysis from a research firm, they showed that when telcos embraced NFV, they were able to reduce their capital expenditures by 68%, operating expenses, or OPEX, 67%. And I think the fact here that is even more important than saving money, obviously every CFO wants to save money, right? But we all demand new services faster, that is the reality of the world we live in. And so the timeline to introduce a new service, once telcos have fully embraced this kind of NFV world, can be reduced from 15 months down to just six months. And so you can imagine in a competitive landscape that if you don't embrace this, you're going to be in big trouble, but if you're the first one, you're going to have a huge opportunity. And as you might imagine, many of these people are banking on open staff, as a core part of that solution. There are many other components that are part of this transition, but if you look across the entire networking industry, on this slide I tried to look across everything that's going on networking and understand these are companies large and small that specialize in networking. You know, all of them are going after that $10 billion opportunity, right? Why wouldn't they? I mean, they're customer base, their customer bases want that speed, they want that cost savings. And so because I love data, I decided it would be fun to look across the industry and see which of these networking companies were betting on open stack as part of their path to market. And so what was really cool, I wanted to highlight, is that the top five largest networking companies in the world all are betting on open stack. They're all working on plugins for Neutron, they're working on NFV solutions. So I think that speaks to open stack as the default de facto component in a bigger platform for going after SDN, going after NFV. And then I wanted to highlight a few of the other companies when we looked at the list to see who from the rest of the market, including startups like Mito Kura, which is right here in Japan. Do we have anyone from Mito Kura here? Cool. So in a conda, there are many interesting startups as well as larger companies. We heard from NEC yesterday. What we found is the people that are betting on open stack is actually all of them. So every single one of these companies is working on a strategy to get to market for software defined networking. Many of them are also targeting that NFV use case based on open stack. And the reason is that open stack fundamentally is an integration engine for new technologies and addressing new markets. And so I've talked about this a little bit in the past. I think Jonathan may have touched on it yesterday. But really it's about looking at the technologies that are emerging over the next 10 years and building a platform that can take advantage of those, can bring them into market, bring them into the data center under one roof, under one API. That's what we hear from users they're interested in. And so last but not least, I wanted to just touch on Neutron itself, the software in the Liberty release. Just highlight a few of the key areas where there were big improvements directly driven by user requirements. So one of those areas is role based access control or RBAC as people that love acronyms like to call it. So if you think about the security world we live in now, it's never been more complicated and more complex to navigate. But in the area of networking, being able to have fine grain controls over who can create networks, who can destroy networks, who can configure them or reconfigure them, that's very, very important. And so there were a lot of improvements in Neutron in the area of role based access control. Another area that we saw improvements to address really a barrier to some users and enterprises from adopting OpenStack at all was IP address management. So this feature was really about allowing enterprises who already had IP address management systems to plug them in. So if you think about the philosophy of OpenStack as an integration engine being pluggable by design, this is yet another example of that in the area of managing IP addresses which I think we all know can be quite daunting. And if you've already got a solution, you certainly don't want to have that just to adopt OpenStack. And then in terms of NFV, there was a lot of work that went into the quality of service APIs. And the NFV use case, I talked about how it's a trillion-dollar industry, this telco business, but at the end of the day, you have to make sure a phone call goes through, text message goes through, WhatsApp, whatever your messaging platform of choice is, quality of service ensuring that you have guaranteed delivery in the time you expect is really important. And it's quite a bit different than some of the requirements for say a web front-end or other use cases that we might have expected for OpenStack early on. And so it's great to see the investment in this. And the work will of course continue, but to talk more about Neutron, someone who is intimately familiar with it, I wanted to bring out Kyle Messery, who's the Distinguished Engineer from IBM, and he was the Project Technical Lead, or PTL as we call them, for Neutron in the Liberty Cycle. So let's learn a little bit more about Neutron from Kyle. Thank you. Good morning, everyone. So I thought it'd be really good just to reiterate again a great thanks to everyone who contributed to Neutron during the Liberty Cycle. So I'm going to talk a little bit about OpenStack networking and Neutron here. Before I really get started talking about it, though, I thought it would be useful to talk a little bit about some quantum history here. So we all know that OpenStack has been around for five years now, founded in July of 2010. So if we look at where networking really kind of came to play, where Neutron and Quantum kind of came in, that was in April of 2011 at the Diablo Summit in Santa Clara. A bunch of interested parties all got together and decided they wanted to make a new networking API. So this is where we all met. We all kind of started to spec it out and everyone began to work on it at that point. So then, let's fast forward a little bit more, September of 2012. This is when Quantum at the time actually was part of the Folsom release. So who here is wondering when I'm going to talk about Neutron? That was a joke, just in case. So this is where we talk about Neutron. October of 2013, the Quantum project was renamed to Neutron at that point. So now let's fast forward a little bit more. We'll jump ahead to the Liberty release. I think as Mark said, Neutron was a pretty active project. If you look at all of the metrics, you look at all of the data, we were pretty ranked pretty high, at least in the top three for most things as well, whether it's code commits, reviews, lines of code, all of those metrics. But I think most importantly, the team was most proud to be number one in yak shaving. So that was definitely it. Okay, is everyone awake out there? I was just like, yeah. There we go. Okay, so let's shift gears a bit. Let's kind of talk about the design goals for Neutron. What were you thinking when we came up with it? The main thing was we wanted to have a unified API. We really wanted to have that logical abstraction, that logical API that we could kind of converge on and that we could have everyone build plugins and drivers for. So we wanted Neutron to be a small core. We wanted it to be very tight like that. We wanted it to be pluggable. I think as Mark said, I mean everything in OpenStack is pretty pluggable. So Neutron should be no different. And really this would enable us to have a growing ecosystem, kind of where we find ourselves today with 60 plus plugins and drivers for everything in Neutron and that. And really we wanted this to be extensible as well. So let's just kind of level set and take a look at these core Neutron abstractions here. So everything on the top is not in Neutron. So those could be things either from virtual machines or containers or bare metal and either virtual or physical interfaces. Those abstractions are outside of Neutron. It's the things on the bottom that are actually the Neutron abstractions. And really there's kind of three core abstractions there. Those are virtual ports, virtual networks and virtual subnets. And these abstractions, they actually are pretty powerful because they let you build something like this right there. So you could build these kind of complex logical topologies like this using those abstractions with things like overlapping IP addresses, multiple routers, these types of things. So it's a pretty powerful set of abstractions. But then we decided, what if we want more? What if we want to extend those core abstractions? And so yes, we came up with that. We have extensions to this. And there's quite a few common extensions like API that are actually pretty useful and almost everyone implements them, things like port binding and DHCP, L3 routing, provider networks, quotas and security groups. So all of this kind of combines to provide a nice rich networking API which is kind of where we find ourselves now. So then the next thing that we looked at and the team looked at was services. What other networking services can we add and what else can we do there? And so we started off doing load balancers. So load balancer as a service was the first service that we did. That's actually on version two of the API now at this point. So that's kind of iterated past the first version. We have a VPN as a service, virtual private networks. And then we have firewall as a service as well, which is currently undergoing a transition to version two of its API as well. So this is pretty good. So we have a lot of new things on the horizon as well. New APIs, new services that the team's been working on at this point. This includes things like Layer 2 Gateway, which allows you to take tunnel overlay networks and dump them into VLANs on top of RAC switches. A lot of people really like that functionality if they're using overlay networks. Service function chaining, which is actually going to be a port-based service chaining function, which that work's been going on for about six months now. Then we have some other projects like BGP, MPLS, VPN. We have a project called Octavia, which is out there, which is the default reference implementation for the load balancer V2 API. So there's lots of new work going on. The team's expanded into a lot of different directions here as well. But now, I thought it would be interesting to kind of look at where the industry kind of finds itself. So we all kind of started off with bare metal. We kind of moved to virtual machines. And now we're all looking at containers at this point. Containers are the new hot thing everyone's looking at. So kind of both figuratively and literally, what ties all of this together? It's actually networking. That's what ties all of these things together. So I wanted to talk just for a brief moment about something called LibNetwork. So LibNetwork is a networking abstraction that the Docker team has been working on at this point. And as you can see, it has some core attributes in there. It has things like sandboxes which hold configuration, endpoints, and networks as well. So you can build container topologies that look similar to this. Now, you might be asking yourself, where have I seen that before? It looks pretty familiar, doesn't it? Well, it turns out that these two abstractions actually go together pretty well. So you can look at the LibNetwork abstraction, and it looks similar to the Neutron abstraction as well. So that's where I'd like to talk for a moment about Project Career. Project Career aims to be the integration point between LibNetwork and Neutron. And I think the most important thing of what Career is trying to accomplish is it's going to allow operators who are utilizing Neutron to use that infrastructure for container networking as well. That's a pretty powerful thing if you already have an investment in that infrastructure. And so we're also working towards integrating this with Magnum as well so we can take advantage of it. So there's a lot of work going on with Career. And there's actually a talk today at 1205 if you're interested in learning more. This is just a really brief slide showing the Career architecture. The talk at 1205 will show you more. But what I'd like to show you now really quickly is just a quick demo of what Career looks like here. Okay. We're doing that. So this demo is essentially what we're running here is we're just running Career. We've got Docker running as well and we have Neutron with Keystone for authentication. So Neutron is going to handle creating all the networks that the Docker calls make. So let's do this. So we're going to go ahead and do this while this is going on now. And of course that didn't work. That's just awesome, isn't it? No, no, not Wi-Fi. Even better. Interesting. Well, there you go. That's where that is. Okay. So anyways, you know, you've rehearsed something so many times, right? At least you know it's a real demo, right? Essentially. So what I was going to show was essentially, Career is able to is able to be the back end. So when you're making CLI calls from Docker to create networks, to create and publish services and things like that, that's all being handled by Neutron on the back end. And the demo was utilizing OVN as the plug-in there. But it's also worth noting, as you can see on the slide, that we also support OpenVswitch, LinuxBridge and Midonet. And really one of the powerful and the only piece of code that you kind of have to add to integrate with LibNetwork for this. So there's a lot of really great things that you can do with that and really that's all that you need. So like I said, there's a top coming up at 12.05 today. You can learn a lot more about Career as well. But yeah, so that's it. So thank you very much. Thank you, Kyle, for braving the demo gods. Thank you again, and they don't always smile on you. But I was talking earlier about how many people are running Neutron in production. And one of the great things about Neutron is there are many different ways you can deploy it. So we're going to be hearing from several users throughout the day that are running Neutron in production. And it's not just about SDN, right? It can provide basic network functionality if you're not ready for SDN and it may never be part of your use case. So it'll be interesting to hear the different decisions that were made from each of these users. And to start, I want to actually welcome up Toshio Nishiyama, Senior Vice President from NTT Resonant to hear what they're doing with their OpenStack Cloud. Please show them a note. Okay. Good morning, ladies and gentlemen. My name is Toshio Nishiyama. And I'm Senior Vice President of NTT Resonant. First, I'd like to express my heartfelt gratitude for receiving the Super User Award yesterday. Thank you. Thank you. I look forward to the NTT Group being supported in the future as well as a member of the community. Today, under the title Case Study on the Use of OpenStack on a large web portal site, I'd like to talk about how we use OpenStack and also about its value to business. First of all, I'd like to introduce ourselves. NTT Resonant operates GOO, a web portal. GOO is a website designed for Japanese users. So our international visitors may not be familiar with it, but it's Japan's third largest web portal. By benefiting from the know-how, we have gained through operating GOO over many years. We also develop and operate websites for corporations. Of course, we are a member of the NTT Group and NTT Resonant is a subsidiary of NTT Communications as well as NTT Docomove. If you are interested, please access URL. Anyway, GOO is a normal portal that has 1 billion page views per month. A large variety of web services are available through this portal site. Our portal is still continuing to grow. This year, the number of page views increased by 15% compared to last year. And GOO is celebrating its 18th anniversary this year. Now, allow me to move onto my main topic. There are three reasons why we introduce OpenStack. First, as a web business is one where things change very quickly. Business speed is the utmost importance. Therefore, we were faced with an urgent need to reduce the period between service design and release. What we needed was an environment that allowed us to respond quickly even if our services experience explosive growth. Second reason requires almost no explanation. Namely, cost reduction is a linear challenge for all companies. In the past, we have operated schemes for the creation of VMs manually. However, provisioning not only takes time but also requires operating costs. Therefore, it was necessary to further reduce our packs. Finally, there was another important reason for adapting OpenStack which is that the entity group had built up considerable technological knowledge in OpenStack. We had expected that taking up the challenge of using OpenStack is a wealth of experience. For these reasons, we decided to use OpenStack with the support of other entity group companies. To construct a new system, we used the IceHouse release which was the newest version of OpenStack at the time. We are using it as a private crowd to provide web services. It was been a year since the new system started operation with more than 1,800 VMs continuing to operate on 400 hypervisors. We began reviewing the introduction of OpenStack in April 2014 and started operating it in October last year. We introduced it in only six months. I'd like to believe that the system introduction and design policies broadly, I have three key points. The first point is that we limited our selection of components so as to introduce OpenStack in a short period of time while ensuring its stability as a platform. We used an OpenStack package developed by the company. We did not make any particular change to the function of OpenStack which serves as the core. Although it is an open-source software, making too many changes to the API is highly likely to create obstacles to updating to newer versions or to adding new components in the future. Secondary, we worked to achieve integration with the existing operational tools and rules. Originally, our company fully adapted Puppet to manage server configurations. We also used Puppet to manage and install OpenStack. In addition, we also developed a system that allows Zabix to semi-automatically monitor VMs in a cloud where VMs are repeatedly created and deleted. The third point is that we took up a challenge on the next stage in development in collaboration with NTT R&D. We adapted Neutron for network control for development of SDN or NFV in the future. At present, we control VM with Neutrons provider network features. We have been operating the new system in a reliable manner for over a year. It is also a challenge for us to feed and nourish that we have acquired through this experience back to this community. The next feedback is the code that together with R&D, we submitted to the community after revising it for bugs. Next, I'd like to explain the effects that OpenStack has had in our company. First, we could greatly reduce delivery and deployment time. Previously, it sometimes took three months to release a new service especially when we needed to procure physical servers. Currently, it generally takes only two weeks. In addition, we are now able to respond flexibly to requests from service development teams. The new system allows us to scale out quickly in response to rapid service growth. In fact, despite having created more than 1,000 VMs in one month from the release of a private cloud, we have experienced no difficulties in providing service services. In terms of operating cost, the new system enabled service development teams to control VMs through self-service. The new system also helped reduce bugs. Finally, a few words about our future plans. This business year, we plan to verify rolling updates from Icehouse. Needless to say, we are aiming to approach Mitaka. We hope to develop a system that can support continuous updating. One more thing, at present, we are using a hardware load balancer and we are reviewing the possibility of providing neutron earbuds by controlling the balancer from OpenStack. In next business year, we plan to try our self to introduce a distributed storage system. If we can use storage freely, we will be able to further widen the range of applications. In a more distant future, we aim to create a world where multiple data centers can be treated as a single virtual data center. This could also be a goal for this community as a whole. We have many challenges which are all worth taking up. Finally, entity residents will continue to contribute to technological development together with the other entity group companies. We look forward to receiving your continuing support. Thank you very much for your attention. Thank you. Thank you so much. Those of us who have traveled here or aren't from Japan may not be familiar with NTT Group as a whole, but it is one of the four largest companies in Japan, one of the top 50 largest companies in the world. That's one of the reasons why they won the Super User Award because they have many divisions that are running OpenStack at scale. In addition to NTT Resonant, there are other entity divisions and they will be speaking throughout the week, so I encourage you to seek out those sessions and learn what all the different groups are doing. Just as a recap of some of the things we've talked about this morning, I think that one of the things about having an integration engine like OpenStack is it really gives you the opportunity whether you have containers, bare metal, if you're looking at NFV and you want to tie it together with SDN to really be able to do that on one platform. This is what we hear users asking for and that's what we're looking to deliver here as we think about Mataka and beyond in the Design Summit. One last point on the Courier demo, there is actually going to be a second attempt at this amazing demo downstairs at 1205 in the Kyoko room. If you liked the idea but want to see it actually work, I would head to that room. It may be quite packed. I think a lot of people are interested in that, but this one platform is really what makes the OpenStack Power Planet a reality and that's what we're all excited about. Next up, we're going to be hearing from Rackspace and they've got some really cool demos and news as well. They're going to start off with a quick video.