 Um, should I start? Oh. Okay. All right. All right. Thank you for coming. Okay. So, I guess I'll start. Ready? Okay. Um, hello there, my name is Machi Hoshino, and I'll be talking by the title of build your own web portal using OpenStack APIs and services. Okay. I guess I'll switch that here. Okay. So, this will be the outline of my presentation. In the introduction, I'll try to explain why I prepared this session today. And on the second chapter, from a user perspective, I'll try to explain what OpenStack means to us, and then, um, why and how we build web portals on top of OpenStack and our future plans in the summary. Okay. So, who am I? Um, again, my name is Machi Hoshino. Um, on the slide there, I believe in pink, you can see four kanji letters. Maybe it's a little bit small, but that's how I write my name in Japanese. Um, if you're aware of Japan, all kanjis have meanings. They mean star, field, truth, and knowledge. Well, thank you. Um, I work at a company called IBM Systems Engineering Japan, and I believe you all know the first three letters, but yes, we are a subsidiary of the IBM group. Um, however, usually we are called ISE in Japan, um, because of the first letters of IBM Systems Engineering. Um, my company is located at a prefecture called Chiba. If you know about Japan, if you're really familiar with it, it's actually close to Tokyo, and I put a picture of the building that I work at and the colleagues that I work with. So, what do I do? Um, in the past, I used to support IBM Power Systems. Now, I don't believe everyone knows that, but, um, it is IBM's proprietary mid-range servers. And I've worked in that field for like five years. Now I support clients designing and building cloud environments, and although I do support a lot of products, um, these days I spend a lot of time supporting OpenStack. And I listed the clients that I and we, meaning ISE, worked with. These clients include Ms. Hobank, Toshiba, Keering, and JFE Steel Corporation. Okay, so, before I really go into the details, I thought this was a great opportunity to show how OpenStack is doing in Japan. And last year, 2015 was a great year. Um, as all of you probably remember, we had our last OpenStack Summit at Tokyo on October. I was actually there as a listener, and I'm very overwhelmed that I'm back here as a speaker. And the second point is that, um, I believe some of you have already got it, the certification program. I believe the community now has a global program, but in Japan we have our own program. It's called Opsil, which stands for Certified Exam for OpenStack Professionals. And this was also started at, um, October on 2015. And last but not least, we're seeing a tremendous growth in the IT market. Um, IDC audiences are saying that we will see a 114% per year growth in the IT market in OpenStack. And I put a graph on there. The last part is 2019, but you can see it's getting big. And you can see that OpenStack is now getting very popular in Japan. So you may wonder what the clients are really getting from OpenStack. On this slide, I've listed some of the clients that IBM Japan worked with and the outcomes they got from OpenStack. To Shiba, they built a service menu on top of OpenStack, and they've achieved flexibility and rapid deployment. Caring, and I believe this is a very big number, but they have reduced their single server cost on 75%. And JFE Steel Corporation, they're estimating that their system build will reduce from two months to 10 days, which is, again, if you calculate that, it's about like 80%. So you can see that a lot of our clients are getting positive outcomes from OpenStack. So in Japan, OpenStack is doing great. Um, I feel that a lot of our clients are really getting interested in this technology. Um, I get a lot of calls, I've spent busy weeks. I'm very confident that this technology, well, of course, not only in Japan, will be widely deployed in this IT industry. So why am I standing here today? I believe because of my session title, I believe a lot of people are expecting that I'm going to talk about web portals, and I am going to talk about that. But the real message that I want to share is what's written right here, and it's a story about what we did after installing OpenStack. As all of you know, OpenStack is now very popular. Clients are getting access to the out-of-the-box OpenStack features. But we have seen that as they fill it around with those features, they start to bump into the question that, well, how can we use these features to really get the best out of OpenStack? So today, I would like to share my experience working with clients and really arguing with this issue, and the one answer we got, which was to build web portals on top of it. OK, so this is what I'm going to talk about today, since it's already here, but since OpenStack has become widely popular in Japan, I believe that we now need to explore how we can use OpenStack. So in this session, I will try, from a user perspective, recap on what OpenStack is, and with demos, I will share our motivation for building web portals on top of OpenStack. I'll try to explain what that drawing means towards the end of this session. OK, what is OpenStack? Now, this may become very embarrassing, because I'm going to try to explain what OpenStack is when there's probably a lot of experts in this room, but I'm not going to do this because I feel pleasure of being embarrassed of it. Instead, I'm going to do this to show how I understand what OpenStack is, and it will be a lot easier for me to explain why that led to the idea of building web portals on top of it. Since this is very basic stuff, some people may get bored. Be patient. I'll show you the demo after about, like, in 10 minutes. OK, so what is OpenStack? I believe this is a very simple question, but we have multiple answers for this. On the key notes, I believe that there are multiple perspectives for this question. My answer is OpenStack abstracts compute network and storage. That's it. Now, what does that mean? In the slide, I wrote a layer called application. Now, imagine that this application is something that you want to write to control your IT resource and IT hardware. If we have OpenStack, this application only needs to care about the OpenStack. OpenStack will convert those APIs to the actual hardware APIs. OpenStack has multiple projects. I believe you know that, but, for example, Nova Glass Neutron, they all provide different functionalities, but what they all have in common is that they let you control your IT resources without caring what it actually is, meaning that I don't have to care if it's KVM or VMware. So when I explain this to clients, they get the response on, well, why does that have to be done by OpenStack? Well, from an application point of view, I believe there's lots of good stops when OpenStack exists. The first point is that OpenStack, first of all, provides a out-of-the-box framework for integrating compute network and storage. If we do not have OpenStack, I have to write every procedure to control the hardware on the application, meaning, like, for example, creating VLANs, assigning IPs, cutting LUNs, assigning those LUNs to the hypervisors, formatting those LUNs, blah, blah, blah, if I have OpenStack, all of that will be merged into a single simple API, which is Nova Boot. And that will save a lot of time building these type of applications. And the second point is that, since OpenStack is now very popular, instead of just having your OpenStack instance on your own data centers, we can have access to OpenStack from public services. For example, IBM now has a private-maged cloud service called Bluebox. So theoretically, if I once write an application based on OpenStack APIs, I can move this application to any OpenStack platforms. And the last point is, since a lot of vendors have helped develop OpenStack drivers, with no code change, we can access proprietary hardware solutions. So what this means is that, with the Nova Boot API, I can control KVM instances and PowerVM, which is IBM's proprietary virtualization solutions. So you can see from an application point of view, OpenStack provides a lot of good points. So I talked about the good things about OpenStack. Now I'm going to talk about what we should consider about. Now, when I say OpenStack provides abstraction to compute network storage, I'm only talking about the core of the OpenStack. And I believe OpenStack is not just I ask, and I brought the big 10 picture. I believe a lot of people know this if they have touched OpenStack. But what this really means is that, when we look at projects, there is two things. First core services and big 10, and in the core services are the projects that have a very long history and provide the basic I ask functions, which is the compute network and storage. And when we look outside of the core services, we have a world called big 10. And well, when we look at these projects, as we see, like, for example, Sahara, which provides Hadoop as a service, and Trove as a database as a service. So you can see that OpenStack is now not just I ask. But so when I explain about the big 10 to my clients, I know I'm exaggerating this. But I always get some responses very close to this. So since OpenStack is very, I mean, has a lot of functions, we sometimes assume that well, if we install OpenStack, all the problems we have will magically go away, which I believe a lot of people know that that's not correct. So can OpenStack solve everything? Is there people that says yes? I believe who says yes? Okay, there's no one. So the answer is probably no. And for a long time, I believe this will be no. And why? Well, because each project have different maturities, I'm glad that the community now provides the OpenStack project navigator. But when we look at this, we realize that the projects that have the high majority are mostly the core services. The big 10 projects Horizon and Heat have high majority. But all the other projects, they're still in the progress of development. And the second point is that not everything is implemented in OpenStack. For example, when I talk to clients, they usually say that they want to trace each user's activities, meaning they want to trace, they want to know person A, build how many VMs on this week, person V, destroy how many VMs on this week. I believe CELAMIR is supposed to do that, but I never really got that to work. And the third and last point, I say to clients that OpenStack cannot solve everything is because OpenStack is difficult. I'll talk to you about the next slide. So I said that OpenStack abstracts compute and network and storage. Now why can that make it difficult? I say OpenStack is difficult and difficult to the users that just want the services. For example, let's say there's a user that says, I want a WordPress server. I want to create an awesome web blog using WordPress servers. And he goes into his OpenStack server. And if OpenStack is really wise and just says, hey, here's your WordPress server. I believe that is easy, but in reality, what we really need to do to get the WordPress server working on OpenStack is to really follow these orange boxes, procedures, to really get it. And so what I really want to say is that OpenStack has made things a lot easier than I knew, than I started working on Parasystems. However, it's the benefit is really for the people that were maintaining and operating the IT hardware. And I believe there's still a lot of people that really don't care about IT hardware. They only care about applications. And for those people, OpenStack is too difficult. We need to make OpenStack much easier. We need to abstract OpenStack. So what is OpenStack? What I want to say in this chapter is that, first of all, OpenStack abstracts compute network and storage. And like I said, OpenStack does not solve everything. And OpenStack is difficult. Difficult for the people that just want the services. So when we develop solutions on top of OpenStack, these are the things that we need to consider about, okay? So how do we do that? So I finally go back to my title, Building Your Willing Web Portals. So in the last chapter, I've talked about the good things about OpenStack and the considerations. Now, how do we overcome that? I believe there are three points for this. The first point is to let's provide a service perspective web interface. Meaning that this is the web I'm talking about. And we really have to care that this is not Horizon. We are not going to show everything what OpenStack can do to the users. We're just going to show the things that the people really care about. So first, let's provide a web interface. And two, when I talk to OpenStack, a lot of customers, they tend to use functions that are really still in the progress of development. So I always tell my customers, if you want to start using OpenStack, start with the basic functions, which are the compute network and storage. I have a customer, I wasn't involved with this customer. But I had a customer complaining that he was trying to work a DVR solution, which only started working. And he complained at me that it's not working. He doesn't get network connectivity. And at the end, I told him, well, why did he use DVR? He started using DVR on VLAN. So why didn't you do that? Why did it start more easier? So I always tell my clients that if you're starting OpenStack, let's start easy, start only using compute network and storage. So now, what do we do with the functions that are not compute network and storage? When we look around this, OpenStack is not the only automation tool. For example, for software installation, I believe a lot of people use Chef, Puppet, Ansible, for project management, maybe Redmine. My answer is that why don't we just combine all these softwares and make it into our own cloud environment? Now, I make this sound easy. From the keynotes, I was actually very amazed from the AT&T's. But I believe a lot of people are trying to do this. They're trying to really integrate a lot of the tools and make it into a single application. But when I talk to clients, I believe this is the most harsh part because now I'm involving multiple technologies. For example, in this chart, I'm involving a web application interface and the OpenStack and Chef, Puppet, and Ansible. So it's really hard to imagine how this all works together. And all the clients that I work with in the end, we always have to argue how to combine the things that are not OpenStack. So today, to give you a better understanding of what I just explained, I brought myself a demo application. This demo application, first of all, it's a video. I'm sorry I didn't believe the demo gods. But this is a demo application. It's a video and it was built by my team back in Japan. And it is really a blend of all the ideas we've got really arguing with our clients. Now, what you are going to about to see, it's not for production use. There's still funny things about the user interface, but it's only built by the purpose to give you a better understanding of what I've just explained. I'll just show you the video first and go into the technical details later. So let's think of a very simple scenario. A guy named Member says that I want a WordPress server and he logs into his web portal. And he does his customization by saying, I want it to make a scale. I want three servers in low balancing. And before he gets his server, in this demo, I will have a approver approve his request. And after it gets approved, he gets his server. Let me switch to the video. Okay, so first of all, I will log into my web portal and I'm entering the URL and there's a screen call I've been cloud orchestrated. I'll tell you what this is after the video, but I'm going to log in there and well, I have an awesome web blog plan, so I'm going to get a WordPress, so I press the WordPress request. And what happens is it's actually me for some basic information. So I'm just going to drill down this. I'm not going to think too much about this. And as you see now, it's asking me how many web servers and how many database servers I want for this. So I'll just say three servers, add some memory on it and boot, add some disk on it. And for the database server, it's asking me for additional disks, so I'll just add 100 gigabytes. And I'll press next. And so now we have a page that's asking for the attributes for the WordPress server and the database. I'll enter a name called ISEDB and here's a fancy feature. It's asking for the load balancer configurations and I'm just going to really drill down the choices and I choose HTTP and I'm going to ask a... So this is a demo. I'm going to enter a very crazy part, number one, two, three, four, five, and 192.168.85 for the external access. Please remember this. You'll see this after. And then I can get next. And now I'll show you a very fancy feature that says show heat template. Now what that did was actually it automatically created a heat template from the user input I just did. I'll explain this after this. But you can see that one web server is there, two web servers there, and three web servers. So this template is actually automatically created. And then I press request. So now I'm waiting for the approver to approve this. So now a mail goes through the approver. This is actually a mail server, and he says, dear approver, a new WordPress request has arrived. Please log in. And so, okay, I'll log in. Now I'm going to log into this portal as the approver. And then what happens is there's a box that says claim task. And I can see the same request that was done by the member guy. And then, well, I'll just say approve. And what happens after this is now the server gets provisioned. And now I only have to wait for the servers to get ready. Well, since there's a little bit of software configuration, I'm going to cut this, but it's not like an hour process. If I can see this, okay. So you can see that it only took like five minutes. And if I click the new mail, it's telling me that your server is ready and you can see the crazy port number one, two, three, four, five that I entered in the screen. And if I click that, I get my WordPress server. Now I can create my awesome web blog. Now the scenario ends here. In real cases, he's just going to create web blogs with this, but I believe we are open stack hackers. So let's see what happened in the open stack side. Now I'm going to log into Horizon. Now in real cases, we should not let the user log in, but this is just for demo. So I'm just going to log in there. But this is the IBM version of Horizon. Don't be abstracted with that. It's basically the same thing, but it's when we log in and there's an orchestration stacks. And you can see that there's a stack created there. Five minutes. And if I look at that, you can see that it created a very complex structure of heat template. But it's really the same thing that you saw on the show heat template button. And well, I believe you can compare it, but it is the same thing that you saw in the previous show heat template button. And if I look at the events, I can see all the events worked fine. And like I said, I could figure a little balancers. Let's see if it's working right. So three web server members. So I'm just going to delete two members. Since I have one member left, I still should have access. And I still have access to that. So I'm going to delete the last member. And I believe there's just a little bit of cache. But after two reels, you can see that the server is now unavailable. So you can see all is working nice. Okay. So let me explain what you've just saw. That demo was a combination of open stack used as IS configuration and Chef used for software configuration. As you have saw, open stack heat was heavily used for this demo. And for the service UI, I use the proprietary software called IBM Cloud Orchestrator. Now, in IBM, we usually call this ICO, but ICO is a great product. It helps you create that type of web application very easily with open stack APIs. Now, since we built it on ICO, this demo application will only work with ICO. But the basic idea is I believe will work on any type of web application platform anyway. So instead of the three points to how to get the best out of open stack, we implemented some fancy features to show what opens stack can do. And the first feature is what you just saw, the automatic heat template creation. Now, for those of you who don't know, how many people know what heat is? Okay, I believe a lot of people know that. So for people that don't know what heat is, it's a technology that is used for template-based deployments. For those of you who know what heat is, how many people have ever write a heat template by themselves? How many people use text editors for that? Okay, a lot of people use text editors. Or not people use text editors for this, but instead in this demo, we created a UI to template converter, meaning that that template was automatically created on the input of the service portal. And for software configuration, we use Chef, and to connect heat with Chef, we use a module called CloudConfig. CloudConfig, I believe a lot of people, some people know this, some people doesn't know this, but CloudConfig has a module that can connect Chef and execute Chef recipes at default. I believe two days ago, there was a session called Metadata Do's and Don'ts. And they talk about this, so if you're very interested, I believe you should look at that. Another feature that I want to talk about is the automatic helicopter update. So what does that mean? The screen that you saw, the screen that I drove down, it's actually built by OpenStack APIs and Chef APIs. There is no hard coding involved in that. So if I update the OpenStack environment and Chef environment, that UI is going to be updated. So I'll show you a demo about that. This is a very short demo, but okay. So I'm back to the scene where I entered the first screen and I believe that a lot of people forgot this, but this is a part where I entered the new DB name. Like I said, this is automatically created from Chef's API. So let's look at the Chef server part. This is Chef server web GUI, and I've just edited. There's a part that says default attributes, and if I look at that, I see my SQL values with four attributes on that, and it is the same thing that I see in this screen. So if I update this, I should see the same thing. So I'm going to update a new attribute that's called test and give it a default value test and save that value. And what happens is I go back and reload the screen. I see the same thing. So you can see there is no hard calling involved, and these features are really created from Chef APIs. Okay, and the last thing I want to share is that since this demo application is based on OpenStack and Chef APIs, I'm able to run, theoretically I am able to run this on any environment if I have OpenStack and Chef. I'm going to show you a very short demo of that. Okay, so that. I'm back to the part where I approve the request. I press claim tasks, and I see the approval again. So I'm going to press approve. Now, in the previous demo, I've shown you the horizon interface, but let's go deeper. What hypervisor was I running at? And I believe this is very rare, because this demo was actually working at a VMware environment. Now, I say this is probably rare, because I believe a lot of people are using KVM for their hypervisors. But as I've explained, OpenStack abstracts that. If I built this on OpenStack APIs, I don't have to care if it's KVM or VMware. So you can see that, well, it's now actually creating Cinder Volumes, and it's doing it by myself. This is the vSphere client, if you know about that. I believe a lot of people know what this is, but you can see that it's automatically creating all the stuff without any user interactions. So you can see that this demo application can work on any type of hypervisors, and it will just keep on going, so I'll just stop the demo here, but I think I have 10 minutes left. So on the screenshot, what is this? This is a screenshot of an application that is really close to what I've just shown, but is working at a PowerVM environment. What was that? And I say this is very close because this is not for demo purposes. We are actually trying to create this application for a real customer for production use. So you can see... It does a lot of complex things than just provisioning WordPress servers. For example, in this application, I can't show you the details, but it is trying to configure a clustering software using shared disks. What I wanted to say is that this technology, we can use it on any type of hypervisors, and we can use it even on production environments. I do have a demo video for this. If you're very interested, I can show you through my laptop. Let me summarize this chapter. I've talked that there are three points to get the best out of OpenStack, and that's what's written there. With my demo application, I'm very glad if you got a better ad... If you got the... How do you say it? I forgot English, but if you got the idea of that. And with that demo application, one more thing I really want to say is that, well, I get clients asking me, what's the best thing about OpenStack? And I tell them APIs are the best thing. With those APIs, I can really connect these multiple technologies and make it look like a single unified application. You can see that in the demo application, they're really connected OpenStack and Chef. Let's just go on. I believe I have a little more time. Let me talk about what we're trying to do now and what we are trying to show to our customers. This part is basically about infrastructure testing. We get a lot of requests from our customers that they want to automate testing. What testing means. I believe before going on production, a lot of people enter a lot of commands seeing that everything is working right and say, okay, now you can go on production. A lot of our customers say that they want to automate that because their system is getting much more complex and this is taking a lot of time. I would like to share my opinion for this. Why do we do testing in the first place? We do test things because there is how it should look and how it actually is. We want to see that there is no difference between those things. Maybe advanced customers have already systemized this, but I believe a lot of customers are using Excel spreadsheets or Word documents to really maintain how it should look. From those information operators, we write them to commands and execute each command. How do we systemize this? If I can achieve the environment that I showed you in the previous demo, how it should look like are all in the open stack heat templates and Chef recipes. Our team back in Japan are trying to create automated test scripts from that information. Here we are trying to use service spec for those who don't know. How many people know a service spec? Okay, so there's a lot of people. Service spec was built by a Japanese engineer. This is really used for testing purposes. If you write a spec file, this is written in... Oh, my God, I forgot the language. I believe it's in Ruby. If I'm wrong, maybe someone will get married. Thank you. It's written in Ruby. It's called a spec file and a service spec eats those files and they do test automatically. Currently, we are trying to create those spec files automatically from information from heat templates and Chef recipes. Sorry, we're trying to do that. I did get reports that some of these are working. Some of these are not. I hope someday we are able to show this. But what I really wanted to say that if we can really automate everything for our IT provisioning, we can really make these things work and create all these old... and automate all these testings and operations. Okay, so that's end of my session. I think I talked a lot up today, but in summary, what I wanted to talk is that OpenStack abstracts compute network and storage. And it does not solve everything. We need to build something on top of it. So we built a web portal to overcome these considerations. And like I've said, when we really build these type of solutions, APIs are really the keys. With those APIs, we can really connect a lot of technologies, multiple technologies, and make it look as if it is a single application. Okay, that is the end of my presentation. I believe I still have time for questions. Sure. Yeah, good presentation. Thanks. When you talk about the APIs, are you directly using the REST APIs? Okay. Yes, no CLIs. CLI means that we're not using Python key clients. We are using actually REST APIs. All right, so the list that you saw are really... We are using JavaScript to really look at those JSON files, and those are created and parsed from those attributes. Yeah. Okay, and the other thing is, you provide a web portal for your end users, but is there a need for you providing APIs to them for automating their tasks? Like instead of going through a web portal, call the API and build up a spin up a cluster of something. Oh, sorry. The question I believe was, so I built a web portal. Do we need APIs for that web portal? I do get requests for that. The product IBM Cloud Orchestrator already has that function. So it does have a REST API interface. I can make it work without entering those values. Yes. Okay. I believe he was first. I'm just looking at this. You said there's this dependency on the IBM Orchestrator product. Did you consider extending Horizon in order to add functionality? Yes. Well, so the question was, how about extending Horizon? Well, we really, when we work with clients, we realize that people don't use Horizon. I'm saying this because to us, I believe in the room, I believe a lot of people say that Horizon looks easy, but clients that don't know OpenStack Horizon is still too hard. They say that I don't know what to do with this. That's kind of what I'm driving at, right? Did you consider taking the framework that was available on Horizon and then putting your easier workflows in there with the templating, auto-defined values and sensible defaults? Okay. So you're probably saying that you, why didn't you write extensions on top of Horizon? Yeah. First of all, I didn't know how to do that. I believe there's a session about that tomorrow. I believe there was an AngularJS session. So maybe if I know about that, maybe I'll try that alternative. Apparently, I used IBM Cloud Orchestrator. Thank you for your presentation. I'm curious where your team thinks it can go in the future as far as creating applications on top of OpenStack. Right now, we're seeing a lot of things that are still kind of in the analytics orchestration management part of the realm, right? And I'm wondering where you see AppDev going in the future. Okay. So this is a question about creating applications on top is not the only answer. There's a lot of things that we can do with OpenStack. Why do you believe that creating applications is the good thing? Is that the question? Sure. Okay. So, well, I'll just go back to a few slides. So, wait, here's a good slide. Okay. So when we look at OpenStack, like I said, OpenStack is only an iOS provider. So we need to really... And what I see is that there's a lot of things other than OpenStack that customers have. For example, they want to... After provision, they want to change some network configurations and network switch does have REST API interfaces and they want to really connect that. So when we have to do that, I believe that we should really connect all those APIs and so we should build application on top but really extend it and connect all the IT resources that we have in our data centers. So I believe... Of course, using as it for, how do you say it, big data, IoT, I believe is a good answer, but I believe building application is one of the key features for IT provisioning. Is that the answer? Thank you. Any questions? Okay, I believe them. Thank you very much. This was very honor.